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

31–40 of 52 posts

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

#31

Post by tptacek »

mustpax wrote: post #21
igravious wrote: post #18

Earlier quoted context omitted.

Excuse my ignorance: what do you mean by noisy?

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 timeout and would blow up the world if it alarmed in milliseconds.

If you want to sleep "as short as you can", sleep for 0 seconds, or call any other system call to yield your process back to the scheduler.

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

#32

Post by tptacek »

ComputerGuru wrote: post #9
typedef_void wrote: post #5

Earlier quoted context omitted.

is sleep(1) noisy? if so, it might be vs timing attacks

Sleep is noisy. When you do sleep, depending on the hardware, the OS, the configuration, the kernel flags, etc. the minimum you actually get is around 38. But that varies.

Wait, what? If I call sleep(1), you're saying it's going to sleep for THIRTY EIGHT SECONDS?

People, it's right there in the man pages.

Are you maybe thinking about WinAPI's Sleep? That's ms-denominated. It would make sense that attempting to sleep for 1 millisecond wouldn't work, and would build in the time for the scheduler and the timeslices for every other process. We're talking about OpenSSL and POSIX sleep(3).

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

#33

Post by tptacek »

typedef_void wrote: post #5
po wrote: post #4

I bet removing this causes something somewhere to break.

is sleep(1) noisy? if so, it might be vs timing attacks

This has nothing to do with timing attacks and would do nothing to defend against them. Read 'daeken's comment below, though.

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

#34

Post by drawkbox »

jakevoytko wrote: post #15
typedef_void wrote: post #5

Earlier quoted context omitted.

is sleep(1) noisy? if so, it might be vs timing attacks

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:/…

True however Sleep on windows is different than sleep on posix/unix.

Sleep() on windows takes ms.

sleep() on nix takes seconds.

Windows:

    VOID WINAPI Sleep(
      __in  DWORD dwMilliseconds
    );
Sleep(1) is as fast as it can go which turns out to be 15-20ms.

nix:

    #include 
    unsigned int
    sleep(unsigned int seconds);
usleep() can be used for more granular delay on nix.

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

#35

Post by tptacek »

jamesseda wrote: post #24
ars wrote: post #20

Earlier quoted context omitted.

Uhhh. I think you need to study this topic some more. > it is actually more reliable to sleep than to block. by definition blocking is unreliable because you don't know exactly when it will unblock. A block will end when the nic can handle more data. You can't just wait a second and assume the nic can handle the data. That's where the "unreliable" part comes in. You assume it can handle the data, but you are not chec…

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.

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

#36

Post by dschobel »

fourneau wrote: post #13
kqr2 wrote: post #7

It looks like someone forgot to remove the "speed-up loop". http://thedailywtf.com/Articles/The-Speedup-Loop.aspx

That's both hilarious and frightening all at once. Luckily static analysis tools catch that kind of stuff very easily now...

Additionally I think you'd be hard pressed to find a modern compiler (for some loose definition of modern) which would not optimize that loop away.

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

#37

Post by ComputerGuru »

tptacek wrote: post #32
ComputerGuru wrote: post #9

Earlier quoted context omitted.

Sleep is noisy. When you do sleep, depending on the hardware, the OS, the configuration, the kernel flags, etc. the minimum you actually get is around 38. But that varies.

Wait, what? If I call sleep(1), you're saying it's going to sleep for THIRTY EIGHT SECONDS? People, it's right there in the man pages . Are you maybe thinking about WinAPI's Sleep? That's ms-denominated. It would make sense that attempting to sleep for 1 millisecond wouldn't work, and would build in the time for the scheduler and the timeslices for every other process. We're talking about OpenSSL and POSIX sleep(3).

My apologies. Yes, I do mean MS - I started off doing *nix development, but now am doing Win32 programming 18 hours a day.

Please discard my above comment, everyone.

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

#38

Post by someone_here »

dschobel wrote: post #36
fourneau wrote: post #13

Earlier quoted context omitted.

That's both hilarious and frightening all at once. Luckily static analysis tools catch that kind of stuff very easily now...

Additionally I think you'd be hard pressed to find a modern compiler (for some loose definition of modern) which would not optimize that loop away.

At that point they would just turn on the optimizations as an "insurance".

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

#39

Post by xpaulbettsx »

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…

Windows also only guarantees that your process will sleep at least as long as you specify. Not that it will sleep exactly as long.

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

#40

Post by Xurinos »

jakevoytko wrote: post #15
typedef_void wrote: post #5

Earlier quoted context omitted.

is sleep(1) noisy? if so, it might be vs timing attacks

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 average", but I would not rely on that measure.

Timers are hard to get right. Tread warily, programmers! This is one of those areas where it is good to understand some things about the computer hardware behind the software.

EDIT: I should add that the high frequency timer is not a panacea either. It will work for you most of the time, but there are two circumstances that will occasionally trip you:

(1) At least in Windows XP and 2000, there is a KB (I do not remember it now) that explains that for a certain small set of manufacturers, if there is a sudden spike in high load on the PCI bus, the high frequencer timer will be jumped ahead to account for the lost time during that laggy spike. This correction is not accurate. This means that if your initial timestamp is X, and you are waiting for it to be X+Y, wall clock time may be between X and X+Y, but Windows itself altered the timestamp to be X+Y+Z, and your software thinks the time has elapsed. I personally experienced this bug.

(2) You actually have more than one high frequency timer -- one for each CPU on your system. Once you start playing on a system with multiple CPUs, how do you guarantee that the API is providing you a timestamp from the same timer? I remember there may have been way to choose if you dropped to assembly to make the query but that the API at the time did not support a choice. The timer starts upon power-up. If one CPU powers up after the other, you will have a timestamp skew. Some high frequency software algorithms attempt to correct for this skew. I do not know all the details to that now.

Post reply on HN