4 ms·

You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections ope

You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections open. I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level. Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.

londons_explore 4y ago
Google famously tried allowing app keepalives to be synchronised... The scheduler allowed a wakeup in 'approximately' X minutes, and the OS would wake up and run all apps callbacks at once. If any app needed a wakeup at a precise time, then other callbacks at nearby approximate times would be run at the same time too. Overall, the thought was that wakeups are expensive, wakeups that involve the network are particularly expensive, so might as well run them all at once (they tend not to be CPU bound - often much of the wakeup handler is spent waiting for the network to connect and send a packet or an ack to arrive back). This turned out to be a very very bad idea. All it takes is some app to have a 'wake up exactly on the hour', and now all other app callbacks will also run exactly on the hour. End result: Mobile networks get 10 million phones all waking up within a few milliseconds of one another, and everyone wanting to connect, and the whole mobile network fails because it was never designed to have 10 million phones all trying to connect within a few milliseconds. That idea was scrapped.
- jacob019 4y ago
  Seems like adding a random deviation to wakeup times would solve that problem.
  - _flux 4y ago
    Surely we'd be at back square one at that point?
    - usr1106 4y ago
      Why? On a single mobile you want to run all wake-ups together to save energy. That network and the server get them from many users spread out evenly is only a benefit.
londons_explore 4y ago
> if keep alive packets are sent at the TCP leve Unfortunately there are lots of bits of hardware in mobile networks that fake acks - ie. TCP level acks will be received very quickly to indicate the mobile network has accepted the data, and will deliver it at some future time out to the internet. The problem is they still send acks even if the remote end is no longer responsive. So you can't reliably use TCP acks to know if a connection is still alive. You need to send actual data and have the application respond.
- _flux 4y ago
  Well that sounds utterly repulsive. And somewhat pointless. In fact, I choose not to believe it. Is there some document discussing this kind of functionality?
  - londons_explore 4y ago
    Products like this: https://www.enea.com/solutions/traffic-management/tcp-acceleration https://www.enea.com/solutions/traffic-management/tcp-accele...

londons_explore 4y ago

Google famously tried allowing app keepalives to be synchronised... The scheduler allowed a wakeup in 'approximately' X minutes, and the OS would wake up and run all apps callbacks at once. If any app needed a wakeup at a precise time, then other callbacks at nearby approximate times would be run at the same time too. Overall, the thought was that wakeups are expensive, wakeups that involve the network are particularly expensive, so might as well run them all at once (they tend not to be CPU bound - often much of the wakeup handler is spent waiting for the network to connect and send a packet or an ack to arrive back). This turned out to be a very very bad idea. All it takes is some app to have a 'wake up exactly on the hour', and now all other app callbacks will also run exactly on the hour. End result: Mobile networks get 10 million phones all waking up within a few milliseconds of one another, and everyone wanting to connect, and the whole mobile network fails because it was never designed to have 10 million phones all trying to connect within a few milliseconds. That idea was scrapped.

jacob019 4y ago
Seems like adding a random deviation to wakeup times would solve that problem.
- _flux 4y ago
  Surely we'd be at back square one at that point?
  - usr1106 4y ago
    Why? On a single mobile you want to run all wake-ups together to save energy. That network and the server get them from many users spread out evenly is only a benefit.

londons_explore 4y ago

> if keep alive packets are sent at the TCP leve Unfortunately there are lots of bits of hardware in mobile networks that fake acks - ie. TCP level acks will be received very quickly to indicate the mobile network has accepted the data, and will deliver it at some future time out to the internet. The problem is they still send acks even if the remote end is no longer responsive. So you can't reliably use TCP acks to know if a connection is still alive. You need to send actual data and have the application respond.

_flux 4y ago
Well that sounds utterly repulsive. And somewhat pointless. In fact, I choose not to believe it. Is there some document discussing this kind of functionality?
- londons_explore 4y ago
  Products like this: https://www.enea.com/solutions/traffic-management/tcp-acceleration https://www.enea.com/solutions/traffic-management/tcp-accele...