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.
Indeed. The maximum size of packets is a property of the networks
between the two ends of the connection. The MTU (maximum transmission
unit) is typically no more than 1500 bytes. That's basically the maximum
payload of a network-layer frame, i.e. the IP packet including its
headers. The overall Path MTU is the smallest MTU of all networks
between the two ends, and there's probably nothing you can do to
increase that if sending packets across the Internet - data cannot be
sent in 256 kB packets, regardless of what the endpoints might negotiate.
The window size is the mechanism by which the receiver notifies the
sender of how much space it has left in its receive buffer, so that the
sender can back-off or stop sending if necessary. I don't think there is
any negotiation involved, and it doesn't affect the size of packets -
just potentially the rate at which they're sent.
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
Yep. The individual packets will be no bigger. The TCP maximum segment
size is the maximum size of the TCP payload in a single segment. It will
be less than the MTU, since it is set to a value which attempts to keep
the overall packet within the path MTU (so that one TCP segment fits
entirely in one IP packet without fragmentation), and the IP and TCP
headers take up some of the bytes allowed by the MTU.
When sending larger payloads via TCP, the payload is split into multiple
segments, each of which can fit in a single packet. These segments are
then reassembled at the other end.
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.
I don't know about SeaMonkey's internals, but I'd interpret this as
referring to the buffer for transferring data between the application
(SeaMonkey) and the network driver. This is separate from the packet
size or TCP maximum segment size, and typically much larger. There are
overheads in transferring each block of data between application and
driver. Using a larger buffer requires fewer transfers for a given
payload (assuming the payload is larger than the buffer), so less
overhead. This data still needs to be segmented/reassembled for sending
over the network, but that can be done by the network driver. Many
network interfaces can perform segmentation in the interface, in which
case the driver doesn't need to use the main CPU to do that, further
reducing CPU usage.
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
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
