Re: [Haskell-cafe] ANN: network-2.2.3, merger with network-bytestring
On 1 November 2010 09:55, Neil Davies wrote: > How accurate do you need this control of throughput? To get really accurate > rates we had to write our own specialist rate regulated thread library which > accounts for any scheduling delay and can even spin if you want low delay > variance in the packet dispatch times. I don't need particular accuracy, "about as slow as dial-up" and "about as slow as broadband" are good enough for my purposes (merely testing a GMail-like AJAXy web app) and I've got that. But I was curious about how one might get accurate rates if you needed. What project did you need such accuracy for? I imagine a real-time system. What did you write the thread library in? C? Links? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: network-2.2.3, merger with network-bytestring
Chris What you are observing is the effects of the delay on the operation of the TCP stacks and the way your 'sleep' works. You are introducing delay (the sleep time is a 'minimum' and then at least one o/s jiffy) - that represents one limit. The other limit is delay/bandwidth product of the connection hiding of this effect is dependent on the window size negotiated. How accurate do you need this control of throughput? To get really accurate rates we had to write our own specialist rate regulated thread library which accounts for any scheduling delay and can even spin if you want low delay variance in the packet dispatch times. Neil On 31 Oct 2010, at 17:56, Christopher Done wrote: On 31 October 2010 16:14, Johan Tibell wrote: This version marks the end of the network-bytestring package, which has now been merged into the network package. This means that efficient and correct networking using ByteStrings is available as part of the standard network package. As part of the merger, two new modules have been added: Network.Socket.ByteString and Network.Socket.ByteString.lAzy Huzzah! I updated my little throttler program to use ByteString.[1] One thing I'm curious about, that maybe you probably know off the top of your head, is that when I'm limiting the speed, I was merely recv'ing and send'ing at 1024 bytes a pop[2], however, when I did this at, say, ~500KB/s, Firefox is really slow at receiving it, whereas when I set it 4096 it's much faster/more accurate to the speed I intend. Chrome doesn't seem to care. I think the difference is that Firefox is single threaded (select/poll-based?) and has to switch between various jobs while receiving every tiny block that I'm sending. Chrome probably has the receiver in a separate process. So it seems like, short of balancing the package size (at powers of 2) and the delay to get some ideal throughput, it's easiest and probably realistically equivalent to set it to 4096 and just rely on an accurate delay? What do you think? Just curious. This is something I think I'll look into in the future, I really don't have a good feel for typical network latency and throughput. It's not a big deal right now as "56k slow" is all I need to test my web app. [1]: http://github.com/chrisdone/throttle/commit/97e03bfc64adc074c9d1f19c2605cb496576c593 [2]: http://github.com/chrisdone/throttle/commit/30dc1d970a7c0d43c1b6dc33da9deecf30808114 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: network-2.2.3, merger with network-bytestring
(Er, that should be (speed/4), not (speed*4). x4 the block size should be x4 the delay.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: network-2.2.3, merger with network-bytestring
On 31 October 2010 16:14, Johan Tibell wrote: > This version marks the end of the network-bytestring package, which > has now been merged into the network package. This means that > efficient and correct networking using ByteStrings is available as > part of the standard network package. > > As part of the merger, two new modules have been added: > Network.Socket.ByteString and Network.Socket.ByteString.lAzy Huzzah! I updated my little throttler program to use ByteString.[1] One thing I'm curious about, that maybe you probably know off the top of your head, is that when I'm limiting the speed, I was merely recv'ing and send'ing at 1024 bytes a pop[2], however, when I did this at, say, ~500KB/s, Firefox is really slow at receiving it, whereas when I set it 4096 it's much faster/more accurate to the speed I intend. Chrome doesn't seem to care. I think the difference is that Firefox is single threaded (select/poll-based?) and has to switch between various jobs while receiving every tiny block that I'm sending. Chrome probably has the receiver in a separate process. So it seems like, short of balancing the package size (at powers of 2) and the delay to get some ideal throughput, it's easiest and probably realistically equivalent to set it to 4096 and just rely on an accurate delay? What do you think? Just curious. This is something I think I'll look into in the future, I really don't have a good feel for typical network latency and throughput. It's not a big deal right now as "56k slow" is all I need to test my web app. [1]: http://github.com/chrisdone/throttle/commit/97e03bfc64adc074c9d1f19c2605cb496576c593 [2]: http://github.com/chrisdone/throttle/commit/30dc1d970a7c0d43c1b6dc33da9deecf30808114 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: network-2.2.3, merger with network-bytestring
Hi all, I like to announce a new version of the network package, network-2.2.3. You can install the latest version by running: cabal update && cabal install network This version marks the end of the network-bytestring package, which has now been merged into the network package. This means that efficient and correct networking using ByteStrings is available as part of the standard network package. As part of the merger, two new modules have been added: Network.Socket.ByteString and Network.Socket.ByteString.lAzy This release is backwards compatible with the previous release. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
