Lee wrote:
On 3/1/19, Dirk Munk <m...@home.nl> wrote:
The next set of parameters I've adjusted are network buffers.
1. network.buffer.cache.size = 262144 (256 kB)
the default setting is 32 kB, and that corresponds with the buffer size
of very old TCP/IP stacks.
2. network.buffer.cache.count = 128
The number of buffers is increased from 24 to 128.
The total network buffer space has increased from 24 x 32 kB = 768 kB,
to 128 x 256 kB = 32,768 kB. The result is that the CPU activity for
Seamonkey has dropped dramatically, by about half.
You might be right.
I tried setting network.buffer.cache.size set to 262144, exit (i have
SM set to clear everything at exit), start SM again, start logging
(about:networking / logging), goto
https://upload.wikimedia.org/wikipedia/commons/3/3f/Fronalpstock_big.jpg
grep -i "Http2Stream::WriteSegments" log.txt-main.5488
and get lots of
2019-03-02 00:11:26.676000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 29b8117cd10 count=262144 state=4
2019-03-02 00:11:26.676000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 29b8117cd10 count=262144 state=4
2019-03-02 00:11:26.676000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 29b8117cd10 count=262144 state=4
2019-03-02 00:11:26.676000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 29b8117cd10 count=262144 state=4
2019-03-02 00:11:26.692000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 29b8117cd10 count=262144 state=4
exit SM, edit prefs.js to remove the network.buffer.cache.size line,
start SM, start logging, goto the same url
grep -i "Http2Stream::WriteSegments" log.txt-main.5064
and many lines of
2019-03-02 00:24:25.317000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.317000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.332000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.332000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.332000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.348000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.348000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.348000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
2019-03-02 00:24:25.364000 UTC - [Socket Thread]: I/nsHttp
Http2Stream::WriteSegments 1db0255ca30 count=32768 state=4
Can somebody than understands the code verify that SeaMonkey uses the
network.buffer.cache.size setting for how much to read/write at a
time?
Thanks,
Lee
It's very simple. Seamonkey tells TCP the buffer size it has reserved
for receiving data, and TCP scales the maximum window size accordingly.
When the connection with the other site is set up, the window size is
negotiated. If both size can handle this window size, data will be send
in 256 kB packets.
The advantage of using big packets is that it takes far less overhead.
Not the data in the packet is the problem, handling the packet itself is
the problem. That's why the processor has far less to do when you
increase network.buffer.cache.size .
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
