Follow-up Comment #4, bug #49531 (project grub):
I have figured out where the delay comes from, and it's actually 400ms
(GRUB_NET_INTERVAL).
In grub_net_fs_read_real
(http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/net/net.c#n1583), it
checks to see if any packets are ready to process, and then runs
grub_net_poll_cards. I think this causes the TCP and HTTP stacks to process
packets until HTTP decides it has enough packets (20 packets, according to
http.c:277) and sets net->stall, which causes grub_net_poll_cards to quit out
before the time is finished.
However, most reads (fetching a module, reading menu.lst) are smaller than 20
packets, and so this poll lasts the entire GRUB_NET_INTERVAL of 400ms. When
this finishes, it then continues parsing packs and returns when len==0.
Altering the timeout to this grub_net_poll_cards causes a change in the delay
I see in the packet trace.
When the server disconnects, I think it triggers http_err, which sets
net->stall==1 and causes grub_net_poll_cards to finish up early.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?49531>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-grub mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-grub
