Schedulering under FreeBSD..

Nøh, det tror jeg ikke, du har.
Nu kender jeg ikke meget til FreeBSD, men jeg mener at kunne huske, at dit program skal køre som root, hvis det skal kunne ændre prioriteten til noget negativt. Måske er det endda kun root, der kan *hæve* programmets/trådens prioritet.

Det giver også god mening, for tænk nu hvis du kunne mase dit eget program ind foran alle andres... Hvor mange ville ikke gerne have et program, der blev udført først på en given maskine? Under behørig hensyntagen til menneskets svage karakter og væsen, ville det nok ikke kunne bruge til noget...

Der findes (i hvert fald i visse systemer) en real-time-policy, der altid er før de andre, og indenfor denne tråd kan der være forskellige niveauer af prioriteter...

Mvh
Søren

Det var egentlig et svar...

Jeg kører som root, så din første pointe ryger lidt i vasken. Det er jeg nød til for at kunne programmere til RAW_SOCKETs..

Jeg har (nogenlunde) styr på de tre schedulerings policies, FreeBSD tilbyder:
----------------------------------------------------------------------------
SCHED_FIFO (first-in/first-out or FIFO)---The highest-priority thread runs until it blocks. If there is more than one thread with the same priority and that priority is the highest among other threads, the first thread to begin running continues until it blocks. If a thread with this policy becomes ready, and it has a higher priority than the currently running thread, then DECthreads preempts the current thread and immediately begins running the higher priority thread.
SCHED_RR (round-robin or RR)---The highest-priority thread runs until it blocks; however, threads of equal priority are time sliced. If a thread with this policy becomes ready, and it has a higher priority than the currently running thread, then DECthreads preempts the current thread and immediately begins running the higher-priority thread.
On a multiprocessor, threads of varying policy and priority may run simultaneously. A high priority thread is not guaranteed exclusive use of a multiprocessor system. You must use synchronization, not scheduling attributes, to ensure exclusive access.
SCHED_OTHER (Foreground or "throughput"; also known as SCHED_FG_NP)---This is the default scheduling policy. All threads are time sliced, and no thread with this policy will completely starve any other thread with this policy, regardless of their respective priorities. (Time slicing is a mechanism that ensures that every thread is allowed time to execute by preempting running threads at fixed intervals.) However, higher-priority threads tend to receive more execution time than lower-priority threads, if the threads are similarly behaved.
Threads with this scheduling policy can be denied execution time by first-in/first-out (FIFO) or round-robin (RR) threads. Threads in this policy do not preempt other threads.

----------------------------------------------------------------------------

Sagen er den at jeg har navnligt to tråde som er ekstremt tidskritiske, og derfor anvender jeg SCHED_FIFO med en prioritet 31 (som sched_get_priority_min() fortæller mig er max) og 30 henholdsvis. (en er vigtigere end den anden ;o) )
Disse to tråde, henholdsvis sender og modtager ip pakker, og registrer roundtrip delay for forskellige router igennem et ip net.
Så har jeg en tredje tråd, som laver beregninger på disse mange roundtrip delays, men sagen er den at når den tredje tråd kører, bliver roundtrip tiderne højere end de ellers er. (15% højere målt over 200 roundtrips).
Det dur selvfølgelig ikke, så derfor ville jeg prioritere min beregningstråd længere ned end den er. Det som jeg egentlig heller ikke forstår er hvorfor de to måletråde (når de nu er preemptivt scheduleret og med en prioritet på 31 og 30) kører langsomt når min beregningstråd kører samtidigt. Mine to måletråde vil heller ikke kunne 'drain'e systemet fordi de tager ca. 500 ms at eksekvere og bliver kørt med 6 sekunders intervaller, så der er altså næsten 90% af CPU-tiden tilbage). Det som jeg har resoneret mig frem til er at den process/tråd inde i kernen der samler ip-pakkerne op fra netkortet også skal prioriteres højere end andre tidskonsumerende tråde. Det har jeg nok ikke lige mulighed for, så derfor ville jeg nedprioritere min beregningstråd i stedet for.

Men tak for dit indlæg! Du må endelig skrive hvis jeg har taget fejl i mine påstande eller antagelser

Mvh Steffen Schumacher

BTW Beskrivelsen af de forskellige policies er hentet fra noget dokumentation for Tru64 UNIX, men API'en er den samme, så mon ikke også betydningen af de tre policies er den samme?

Kan være, at nogle systemservices har reserveret de negative prioriteter?

Hov! Lavere nummer er højere prioritet, er det ikke? Jo lavere nummer, du giver den, jo hurtigere kommer den til fadet, så vidt jeg husker... but I could be wrong...

Lavere prioritet er ikke altid bedre end høj. Det er OS afhængigt, men jeg har valgt at lægge min tillid til at funktionerne sched_get_priority_min og sched_get_priority_max returnerer det man forventer.. Minimal prioritet og maksimal prioritet for en given schedulerings policy. Men det ka da være at det er møntet på værdien af prioriteten, frem for selve prioriteten.. sådan at hvis -20 virkelig er den højeste prioritet en tråd kan få, at det som sched_get_priority_max returner blot er den højeste tal-mæssige værdi og dermed 20, og sched_get_priority_min så returner -20 fordi det er den mindste talmæssige prioritet. Men det lyder noget mærkeligt. Jeg er ikke kommet videre med det så jeg tror jeg vil begynde og eksperimentere lidt med det.

Hmm jeg tror ikke det er tilfældet med lavere prio = større vigtighed.. Kigger lige lidt videre..

Stadig af samme mening. Hvis jeg giver en tråd en lavere prioritet end en anden vil den ikke få cpu-tid, forudsat at de begge kører konstant.

Hmmm... Er lidt blank lige nu, men hvis jeg finder noget, så siger jeg til...

Cool skriv til steffen (a) bagageboxen (dot) dk

Har indtil videre postet det som en bug på freebsd.org..
sched_get_priority_max returnerer 20 og sched_get_priority_min returnerer -20 for SCHED_OTHER, men det er ikke muligt at sætte prioriteten til noget negativt for SCHED_OTHER. Gad godt at man kunne læse lidt prosa om hvordan scheduleringen forgår i fbsd..