Lee wrote:
On 3/2/19, Dirk Munk <[email protected]> wrote:
Lee wrote:
On 3/1/19, Dirk Munk <[email protected]> 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
... snip ...
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
... snip ...
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.
That is clearly not how it works.
Start wireshark, start seamonkey & download a file. Stop the capture
& find the initial tcp syn to the download site. What I get is
Window size value: 64240
Options: (12 bytes), Maximum segment size, No-Operation (NOP),
Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
TCP Option - Maximum segment size: 1460 bytes
TCP Option - No-Operation (NOP)
TCP Option - Window scale: 8 (multiply by 256)
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - SACK permitted
with network.buffer.cache.size set to 32768 or 262144
The advantage of using big packets is that it takes far less overhead.
Except you're not using big packets. Refer back to the packet
capture; the packet size is negotiated during the initial handshake
with the
TCP Option - Maximum segment size: 1460 bytes
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 .
Right, the processor has less to do when you handle data in larger
chunks - which is why I was asking for someone who understands the
code to look & see if SeaMonkey uses the network.buffer.cache.size
setting for how much to read/write at a time.
In other words, is setting network.buffer.cache.size the best that can
be done or are there more memory-usage/speed trade-offs that can be
made?
Thanks,
Lee
The settings I use now, provide for 32 MB of buffer space, compared to
.8 MB before. The result is far less CPU cycles, so I'm happy right now.
If there is a way to make precise calculations for setting these
parameters, hat would be fine, but I'm not counting on it.
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
