tag:blogger.com,1999:blog-581197352358126527.post5146304364888088265..comments2024-03-28T00:32:25.959-07:00Comments on japh(r) by Chris Strom: Wireshark Graphs and Node-SpdyAnonymoushttp://www.blogger.com/profile/00135361916531185929noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-581197352358126527.post-54632306901493315812012-05-17T21:03:36.064-07:002012-05-17T21:03:36.064-07:00Looks like it might be nothing more than a capture...Looks like it might be nothing more than a capture error: http://japhr.blogspot.com/2012/05/firefox-spdy2-vs-spdy3-in-graphs.html.<br /><br />That's good information to note, but I am fairly certain that node-spdy always sends the same number of packets (the y-axis is sequences), regardless of version. The next night's results suggest that the implementation is more or less solid—but I'll still keep that in mind.Anonymoushttps://www.blogger.com/profile/00135361916531185929noreply@blogger.comtag:blogger.com,1999:blog-581197352358126527.post-30081572697250384552012-05-17T10:50:35.330-07:002012-05-17T10:50:35.330-07:00are you by chance aligning your writes differently...are you by chance aligning your writes differently in a way that could lead to more TCP packets in v3? most TCP implementations measure cwnd in terms of packets not in terms of bytes. (which is kinda crazy, but its a bit stuck like that for legacy reasons). Easy to double check the packet counts in the respective captures.<br /><br />The same number of bytes split over more tcp packets will mean cwnd takes longer to grow to a point that fills the BDP - a lot longer than the small overhead of more packet headers would make it look like at first.Patrick McManushttps://www.blogger.com/profile/00565702107491976279noreply@blogger.com