Ultrafast single TCP packet audio/visual experience • Hacker News Board

Re: Ultrafast single TCP packet audio/visual experience

#61

Post by jstimpfle » Tue, Sep 19, 2017, 3:07 PM UTC

bogomipz wrote: post #58

jstimpfle wrote: post #56

Earlier quoted context omitted.

IP header has flexible size, up to 60 bytes: https://networkengineering.stackexchange.com/questions/6855/...

Sure but on the actual internet how often are IP headers larger than 20 bytes because options are turned on? Not very often. The 20 bytes each for TCP and IPv4 is a pretty good assumption. From the paper "IP Options are not an option" which is good quick read: "We have studied the dependability of IP options-enabled network packets in the Internet. We found that overall, approximately half of Internet paths drop pack…

Thanks, that's good to know. I've wondered if these options are used in the past.

Re: Ultrafast single TCP packet audio/visual experience

#62

Post by iainmerrick » Tue, Sep 19, 2017, 3:08 PM UTC

mypalmike wrote: post #46

Geee wrote: post #41

How is it that loud? It's not tolerable even on minimum settings on my iMac.

Tip: Shift + Option + Volume(up/down) adjusts volume by 1/4 of a bar.

Wow! How did you learn that?

Re: Ultrafast single TCP packet audio/visual experience

#63

Post by jest7325 » Tue, Sep 19, 2017, 3:16 PM UTC

It might be fast but does it handle load? Did you try to benchmark it with a service like https://ddostest.me

Re: Ultrafast single TCP packet audio/visual experience

#64

Post by addHocker » Tue, Sep 19, 2017, 3:20 PM UTC

federicoponzi wrote: post #37

ed wrote: post #12

Earlier quoted context omitted.

Caution: loud

Opened this on my phone with headphones. I had an heartattack.

Branded with bleeding ears. Dolby.

Re: Ultrafast single TCP packet audio/visual experience

#65

Post by convery » Tue, Sep 19, 2017, 3:22 PM UTC

Now I'm curious, could one minimize this further? As in, making Chrome accept UDP to get rid of SYN/ACK etc.

Re: Ultrafast single TCP packet audio/visual experience

#66

Post by sitkack » Tue, Sep 19, 2017, 4:01 PM UTC

kozak wrote: post #36

Looks like the browser spends most of the loading time resolving DNS.

The website should fit in the DNS response.

Re: Ultrafast single TCP packet audio/visual experience

#67

Post by sitkack » Tue, Sep 19, 2017, 4:02 PM UTC

wogna wrote: post #45

Why is the tcp socket set to busy poll for 1 microsecond?

Web Scale?

Re: Ultrafast single TCP packet audio/visual experience

#68

Post by londons_explore » Tue, Sep 19, 2017, 4:23 PM UTC

s_gourichon wrote: post #39

robocat wrote: post #7

http://packet.city/ summary: A demo scene page that is smaller than a single IP frame and uses some flags to avoid other round trips. view-source: http://packet.city/ The page itself and view-source only work on some browsers. Use wireshark etc to see what it actually does.

Wiresharked the thing. Here's the packet sequence it reported: -> DNS query A -> DNS query AAAA TCP SYN TCP ACK -> HTTP GET TCP ACK TCP FIN,ACK So, the full traffic is 14 packet, all small (DNS, TCP handshaking) except the one HTTP reply packet containing the full website.

It's still pretty sad that so many roundtrips are necessary...

One could imagine a merged DNS and TCP syn packet, which goes to a DNS server who converts it to a TCP packet, and gets forwarded to the origin server.

Re: Ultrafast single TCP packet audio/visual experience

#69

Post by londons_explore » Tue, Sep 19, 2017, 4:24 PM UTC

kozak wrote: post #36

Looks like the browser spends most of the loading time resolving DNS.

Get a better DNS server... 4.2.2.2 or 8.8.8.8 are good choices.

Re: Ultrafast single TCP packet audio/visual experience

#70

Post by londons_explore » Tue, Sep 19, 2017, 4:27 PM UTC

Dylan16807 wrote: post #32

mkj wrote: post #22

Earlier quoted context omitted.

Hm. I what the distribution of latency vs bandwidth is like, whether 14kB or 2 round trips takes longer for most people?

Probably the two round trips. A semi-nearby server might be 50ms per round trip, and in that case any connection beating 1mbps can transfer 14KB in less than two round trips. A server could easily be 150-250ms away and make those round trips far worse.

It also depends on the buffer size.

Some routers might only buffer 1 millisecond of line-rate data or less. If that's the case, that initial congestion window of 10 could overflow the buffer, causing loss and a much more costly double-round-trip to resend.