TS on gigibit internet
-
i have the 1gig/35update plan comcastic LOL
would I just go about fixing the bufferfloat issues? anyone have comcast 1gig plan with TS working.. PLease share settings!!
thanks in advance
-
What is your current traffic-shaping config and what other configs have you tried? What are your current issues?
-
If you really only have 35Mb/s up, you're going to about max your upload in ACKs sometime after 500Mb/s. I would break my upload into at least 3 queues using HFSC. A high priority ACK for games, which will not need much bandwidth, maybe only 2-5Mb/s, then a general ACK queue with something like 60%-80% of the remaining, but with a short fixed sized queue, no Codel. ACKs are typically fixed sized, so assuming each packet is ~80bytes and aim for about 10-20ms of buffer because on the queue depth.
The theory behind this, and I have not tested it, is a dense TCP flow is not very sensitive to dropped ACK packets because the next packet(s) will ACK all of the prior packet's data. But TCP is very sensitive to latency. Better to have loss than bloat. A possible exception to this is game or otherwise low bandwidth interactive TCP traffic. This kind of traffic may not have a "next" ACK because no more data is being received. The received data is sparse, not dense, and every ACK counts.
Because this is HFSC, any unused bandwidth from the high priority ACK queue will be split among the remaining queues. You will want enough bandwidth assigned to the non-ACK queue to meet your needs. Of course, you may be trading upload for download because of this crazy high asymmetry.
-
If you really only have 35Mb/s up, you're going to about max your upload in ACKs sometime after 500Mb/s.
Just for anecdotal reference, during a fully saturating download my ACK queue averages ~256kbit on my 12mbit connection, so a 35mbit upload should be capable of supporting a 1000mbit download… barely. Crazy high asymmetry indeed.
-
when I up'ed my plan i deleted all of the TS.. I'm trying to re-do TS with the wizard.. doing the 20% safe zone.. still bufferfloat F. im using HFSC so I just gotta fine tune it.. at this time gaming is no fun lots of lagg.
thanks Harvy66 i will try
-
when I up'ed my plan i deleted all of the TS.. I'm trying to re-do TS with the wizard.. doing the 20% safe zone.. still bufferfloat F. im using HFSC so I just gotta fine tune it.. at this time gaming is no fun lots of lagg.
thanks Harvy66 i will try
What sort of traffic is on your network? Are you getting game lag even when your internet connection isn't being saturated?
Are you getting an F on both upload & download?
-
all kinds of traffic I just adjusted my broadcast and mdns from all the ip cameras and mesh wifi systems i have installed. udp and tcp running plex,hdhomerun cable over network only bufferfloat on download I think..
i set wan to 30 for the upoad
and all the lan's with 950 hfsc Codel Active Queue active -
If you really only have 35Mb/s up, you're going to about max your upload in ACKs sometime after 500Mb/s.
Just for anecdotal reference, during a fully saturating download my ACK queue averages ~256kbit on my 12mbit connection, so a 35mbit upload should be capable of supporting a 1000mbit download… barely. Crazy high asymmetry indeed.
Depends on what layer of "bandwidth" we're talking about. If you assume Ethernet, every 1530 byte Ethernet frame received will result in a 92byte frame sent assuming these frames represent a TCP connection. Nagle is enabled on most systems, so let change that to 92bytes sent for every 3060byte received. That's a 33:1 ratio. 1Gb down will result in 30Mb up of traffic.
This ratio completely changes if you only assume Layer3 data transfers. Then it's 60bytes up for every 3000bytes down, which is a 50:1 ratio or only 20Mb up for 1Gb down. I assumed the worse of the two.
-
Depends on what layer of "bandwidth" we're talking about. If you assume Ethernet, every 1530 byte Ethernet frame received will result in a 92byte frame sent assuming these frames represent a TCP connection. Nagle is enabled on most systems, so let change that to 92bytes sent for every 3060byte received. That's a 33:1 ratio. 1Gb down will result in 30Mb up of traffic.
This ratio completely changes if you only assume Layer3 data transfers. Then it's 60bytes up for every 3000bytes down, which is a 50:1 ratio or only 20Mb up for 1Gb down. I assumed the worse of the two.
A single ACK can acknowledge several received packets. TCP doesn't acknowledge each packet individually.
-
Depends on what layer of "bandwidth" we're talking about. If you assume Ethernet, every 1530 byte Ethernet frame received will result in a 92byte frame sent assuming these frames represent a TCP connection. Nagle is enabled on most systems, so let change that to 92bytes sent for every 3060byte received. That's a 33:1 ratio. 1Gb down will result in 30Mb up of traffic.
This ratio completely changes if you only assume Layer3 data transfers. Then it's 60bytes up for every 3000bytes down, which is a 50:1 ratio or only 20Mb up for 1Gb down. I assumed the worse of the two.
A single ACK can acknowledge several received packets. TCP doesn't acknowledge each packet individually.
It can but only does so in the case of Nagle, which is 2 packets and I addressed above, or you have packet loss. Either way, that doesn't change the fact that you're sending the data. For 99.9999% of network streams, your TCP ingress:egress will typically be either 33:1 or 50:1, depending on what layer you're looking at and what types of layer2s your packets go through.