Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"A sleep(1) is put into all SSL_read() and SSL_write() calls..."

bugs.python.org

Post reply on HN
Print view View original

41–50 of 52 posts

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#41

Post by mustpax »

tptacek wrote: post #31
mustpax wrote: post #21

Earlier quoted context omitted.

Noisy means there is a lot of variance in the actual time the process spends sleeping. When you say sleep(1) most OSes interpret that as saying, sleep as short as you can. Based on the scheduler internals, that can vary a lot.

Which OS interprets sleep(1) (ie, "sleep for 1 second") as "sleep for as short as you can"? On WinAPI, Sleep is denominated in milliseconds. On BSD, sleep(3) is a library wrapper around nanosleep(2). Linux's man pages make no mention of the magic number "1" as a "sleep 1 timeslice" shortcut; also, older Linux man pages warn that sleep(3) can be implemented in terms of alarm(1), which is used all over POSIX as an I/O…

Thanks for the correction. I was just talking about the de facto behavior I have seen on Linux and BSD for very short sleep intervals (way shorter than 1 second), not necessarily about the behavior as specified by the system call. I should have been clearer.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#42

Post by tptacek »

mustpax wrote: post #41
tptacek wrote: post #31

Earlier quoted context omitted.

Which OS interprets sleep(1) (ie, "sleep for 1 second") as "sleep for as short as you can"? On WinAPI, Sleep is denominated in milliseconds. On BSD, sleep(3) is a library wrapper around nanosleep(2). Linux's man pages make no mention of the magic number "1" as a "sleep 1 timeslice" shortcut; also, older Linux man pages warn that sleep(3) can be implemented in terms of alarm(1), which is used all over POSIX as an I/O…

Thanks for the correction. I was just talking about the de facto behavior I have seen on Linux and BSD for very short sleep intervals (way shorter than 1 second), not necessarily about the behavior as specified by the system call. I should have been clearer.

I really don't think you've ever seen BSD return in milliseconds after a 1-second sleep. Respectfully, I think you're pretty much just wrong.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#43

Post by tptacek »

Xurinos wrote: post #40
jakevoytko wrote: post #15

Earlier quoted context omitted.

Sleep(1) is very noisy on Windows machines. The time slice given by default is ~15-20ms [1], and calling Sleep( This crummy Sleep() implementation has some nice effects on programmers. Those who like to solve problems with lots of copy/paste code are forced to think about using proper synchronization primitives when running high resolution loops that wait for events, or their code just won't run very fast. [1] http:/…

When I did driver programming in Windows, it was well-known that Sleep had a resolution of 10 ms; it is based on the interrupt timer (not the high frequency timer). You could change the interrupt timer's duration, but its ticks are what guide Sleep. Not counting the effect of context switching, since you are waiting for the timer ticks, your actual times vary from 10 ms to 19.9999 ms. 15 ms is a nice way to say "on a…

Presumably the high frequency counter is driven off the cycle counter, and not the Intel High Precision HPET Timers.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#44

Post by jamesseda »

tptacek wrote: post #35
jamesseda wrote: post #24

Earlier quoted context omitted.

cool, I'll check the nic status before sending if I ever want to maximize throughput. But I'll probably rewrite it in C at that point too.

"Check the NIC status"? What network API are you using? Even if you're injecting with libpcap, you can still just select() on the device handle.

I am not using an API, I am writing to the driver

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#45

Post by Dylan16807 »

tptacek wrote: post #42
mustpax wrote: post #41

Earlier quoted context omitted.

Thanks for the correction. I was just talking about the de facto behavior I have seen on Linux and BSD for very short sleep intervals (way shorter than 1 second), not necessarily about the behavior as specified by the system call. I should have been clearer.

I really don't think you've ever seen BSD return in milliseconds after a 1-second sleep. Respectfully, I think you're pretty much just wrong.

Read it again. He's talking about near-zero sleep calls, not one second sleep calls.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#46

Post by tptacek »

jamesseda wrote: post #44
tptacek wrote: post #35

Earlier quoted context omitted.

"Check the NIC status"? What network API are you using? Even if you're injecting with libpcap, you can still just select() on the device handle.

I am not using an API, I am writing to the driver

Just use Winpcap instead of wasting time reinventing this wheel.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#47

Post by tptacek »

Dylan16807 wrote: post #45
tptacek wrote: post #42

Earlier quoted context omitted.

I really don't think you've ever seen BSD return in milliseconds after a 1-second sleep. Respectfully, I think you're pretty much just wrong.

Read it again. He's talking about near-zero sleep calls, not one second sleep calls.

POSIX sleep() doesn't take subsecond intervals. Maybe he's talking about usleep()?

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#48

Post by mustpax »

tptacek wrote: post #42
mustpax wrote: post #41

Earlier quoted context omitted.

Thanks for the correction. I was just talking about the de facto behavior I have seen on Linux and BSD for very short sleep intervals (way shorter than 1 second), not necessarily about the behavior as specified by the system call. I should have been clearer.

I really don't think you've ever seen BSD return in milliseconds after a 1-second sleep. Respectfully, I think you're pretty much just wrong.

Well, that is not what I meant at all, I meant that I've seen BSD return in say 2 microseconds after calling usleep(1).

But that's usleep not sleep, which is the inaccuracy I was admitting to in the first place.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#49

Post by Xurinos »

tptacek wrote: post #43
Xurinos wrote: post #40

Earlier quoted context omitted.

When I did driver programming in Windows, it was well-known that Sleep had a resolution of 10 ms; it is based on the interrupt timer (not the high frequency timer). You could change the interrupt timer's duration, but its ticks are what guide Sleep. Not counting the effect of context switching, since you are waiting for the timer ticks, your actual times vary from 10 ms to 19.9999 ms. 15 ms is a nice way to say "on a…

Presumably the high frequency counter is driven off the cycle counter, and not the Intel High Precision HPET Timers.

http://en.wikipedia.org/wiki/Time_Stamp_Counter

"The issue has two components: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. In such cases, programmers can only get reliable results by locking their code to a single CPU."

The entry also mentions that hibernation can affect the counters. I wonder if power savings implementations that speed up or slow the CPU could also have an effect.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#50

Post by tptacek »

Xurinos wrote: post #49
tptacek wrote: post #43

Earlier quoted context omitted.

Presumably the high frequency counter is driven off the cycle counter, and not the Intel High Precision HPET Timers.

http://en.wikipedia.org/wiki/Time_Stamp_Counter "The issue has two components: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. In such cases, programmers can only get reliable results by locking their code to a single CPU." The entry also mentions that h…

Yes. The TSC, which counts cycles, is what WinAPI reads with GetTickCount(), and is not the same thing as the HPET timers.
Post reply on HN