1

I'm doing a Boost asio networking program for Mac OS X based on the HTTP Server 3 example. It uses async_read_some to read data from the TCP socket asynchronously.

The problem is that my handler returns with a very small amount of data. I give it a 64k buffer but it usually returns with about 1448 bytes which is the size of one full Ethernet packet. This in turn causes high CPU usage when there is a large data transfer and I can't imagine all those kernel to user space jumps are efficient.

Is this normal to get data in such small chunks?

Is there a way to tell the TCP stack or the asio framework to try and buffer more data in the kernel before returning?

Matt
  • 13
  • 2
  • Checkout this thread to see if it can help you: http://stackoverflow.com/questions/4933610/boostasio-async-read-guarantee-all-bytes-are-read – Plexico Jan 27 '14 at 19:20

1 Answers1

1

It's really easy: once things become busy, you will start getting larger amounts of data at once. That's all there's to it. Yes, it's very much normal to get data in such small chunks when the system is not loaded. This is in fact the desired behavior: you are taking advantage of low system load to get exceptionally good latency. Things will gracefully degrade from that point, as necessary.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • Thank you for your answer. However, I'm still wondering, wouldn't there be scenarios when one would want to keep CPU usage low trading off lower latency? For example, if I want to reduce power consumption and conserve laptop battery. Isn't it a valid enough scenario to have the ability to tell the TCP stack or framework to buffer data more in the kernel? – Matt Feb 03 '14 at 19:17
  • @Matt Ultimately it's not about who buffers where, but whether the CPU is woken up or not. If a network interrupt had to awaken the CPU and get the kernel busy, there's little benefit of keeping the userland unaware of it. Once you're up, you're up, pretty much. – Kuba hasn't forgotten Monica Feb 03 '14 at 19:48
  • @Matt Of course the TCP stacks are tunable, but it's not only about the stack, but also about hardware. Modern, mobile-aware operating systems do their best to utilize the CPU in the best possible way, so they will, if possible, tune the network adapters to interrupt as less frequently, and to coalesce wakeups from multiple sources. That's why, for example, recent frameworks, like Qt 5, offer coarse timers in addition to precision ones. Coarse timers waste less power. – Kuba hasn't forgotten Monica Feb 03 '14 at 19:53