Steam not working on iBurst.

Please post a link to the WoW issue you were referring too?
 
eltherza said:
I've actually stopped caring on trying to explain to you have p2p packet sniffing adds latency...
Click to expand...

Latency is introduced by the client, air interface, the base station, the PDSN, the core, the distribution layer, the peering, the internationa fibre, and the destination server but by far the largest contributor to latency is distance and frame size.

Latency is typically measured using tracerts and pings in ms (milliseconds), e,g, 175ms to bbc.com. The measured latency for deep packet inspection varies from 17.63µs for a 64 byte frame to 31.18µs for stream containing 1518 byte frames. (µs is 1/1000 milliseconds) That is less than an eye of a needle when compared to a camel.
 
DagegeN said:
Dude something is wrong by your side ... i get 3gig per night from 00:00 to 08:00 so on average i drain 80 gig of torrents per month... maybe check your firewall or port settings.
Click to expand...

I can't download torrentz as well, but don't care, cause I have a ADSL line at work doing that. My steam downloads are normally fine. I am starting to think that almost no one uses the Iburst tower in midrand. ;)
 
r00igev@@r said:
Latency is typically measured using tracerts and pings in ms (milliseconds), e,g, 175ms to bbc.com. The measured latency for deep packet inspection varies from 17.63µs for a 64 byte frame to 31.18µs for stream containing 1518 byte frames. (µs is 1/1000 milliseconds) That is less than an eye of a needle when compared to a camel.
Click to expand...

I somehow doubt the shaped packets go through the shaping device in 17µs, there is latency on the connection to the device, there is latency leaving the device, there are memory access times [which you might have included in this] but ultimately µs is not on measurable scale in pcs at all. The most devastating effect on the latency is not processing time, but queuing for processing.

Here is a good example: 2 packets arrive "at the same time", one has to wait for the other to process before it can be processed, the total time for the 2nd packet to be processed is not 17µs, but 34µs.

Some fancy maths and assuming iburst is going at ~50KB/s - that means at the shaper, it'll receive a 64 Byte every 20µs. Thats dangerously close to the time it takes to process the packet. Throw in another user downloading at 50KB/s and suddenly there is this situation:

packet 1 (17µs)
packet 2 (17µs+17µs)
packet 3 (17µs + 17µs + 17µs)

And it just gets worse, not even taking into account other latencies such as internal network related ones.

Maybe I'm wrong, maybe the bottle neck isn't the shaping device - but the issue is clear that iBurst's has a latency issue, and I'm not convinced it's the over the air problem.

-------------------------

Here's some more fun facts!

The tv show timewarp runs at 675,000 fps on the camera. Thats a picture every 2µs!

If you get 60fps @ 1920x1080 that means it takes 0.008µs for a pixel to decide on it's colour!
 
eltherza said:
I somehow doubt the shaped packets go through the shaping device in 17µs, there is latency on the connection to the device, there is latency leaving the device, there are memory access times [which you might have included in this] but ultimately µs is not on measurable scale in pcs at all. The most devastating effect on the latency is not processing time, but queuing for processing.

Here is a good example: 2 packets arrive "at the same time", one has to wait for the other to process before it can be processed, the total time for the 2nd packet to be processed is not 17µs, but 34µs.

Some fancy maths and assuming iburst is going at ~50KB/s - that means at the shaper, it'll receive a 64 Byte every 20µs. Thats dangerously close to the time it takes to process the packet. Throw in another user downloading at 50KB/s and suddenly there is this situation:

packet 1 (17µs)
packet 2 (17µs+17µs)
packet 3 (17µs + 17µs + 17µs)

And it just gets worse, not even taking into account other latencies such as internal network related ones.

Maybe I'm wrong, maybe the bottle neck isn't the shaping device - but the issue is clear that iBurst's has a latency issue, and I'm not convinced it's the over the air problem.

-------------------------

Here's some more fun facts!

The tv show timewarp runs at 675,000 fps on the camera. Thats a picture every 2µs!

If you get 60fps @ 1920x1080 that means it takes 0.008µs for a pixel to decide on it's colour!
Click to expand...

Your maths is incorrect based on negative assumption. Assume you are correct then by the number of packets being processed on the network your connection would not establish as the latency would result in a timeout. Since I am on an iBurst modem and on this web site that is false, so wrong assumption.

As a matter of interest the rated capacity is 12 million packets per second with 1 million connections, with the technology being used the same as that for the core switching infrastructure.

BTW: the latency of the air interface is the same with or without deep packet inspection (tested it myself).
 
r00igev@@r said:
Your maths is incorrect based on negative assumption. Assume you are correct then by the number of packets being processed on the network your connection would not establish as the latency would result in a timeout. Since I am on an iBurst modem and on this web site that is false, so wrong assumption.

As a matter of interest the rated capacity is 12 million packets per second with 1 million connections, with the technology being used the same as that for the core switching infrastructure.

BTW: the latency of the air interface is the same with or without deep packet inspection (tested it myself).
Click to expand...

12 millions packets per second? iBurst therotical max: 1Mbps or 128KB/s

128KB/s is 2048x64 byte packets.
So that means, if everyone had a max conneciton on iBurst, soon as you have more than 5800 users on the system at the same time will be guaranteeing lag
PHP: 
. But in the real world queuing actually occurs sooner than the theory max.

[quote]
Since I am on an iBurst modem and on this web site that is false, so wrong assumption.
[/quote]

Websites timeouts are rather large, low data requires and most importantly it's goes it bursts, once the page is loaded there is no more load. Websites don't need to be real time [nor synchronous]. Our websites are set to connection timeout at 10 seconds... 10 000ms!

[quote]
latency would result in a timeout
[/quote]

Or... a disconnect in a game? Sounds about right actually.

[quote]
BTW: the latency of the air interface is the same with or without deep packet inspection (tested it myself).
[/quote]

Yeah, I'd assume shaping takes place on a hardware level in iburst's server. I've ignored latency getting to the servers port and the latency once the data leaves the servers port.

----

[B]Don't get me wrong, I'm not fighting against shaping or want things to change. I've accepted this is a limitation on the network that can't really be fixed [business/technological reasons]. I'm just finding this conversation quite interesting (new thread?).[/B]
 
eltherza said:
So that means, if everyone had a max conneciton on iBurst, soon as you have more than 5800 users on the system at the same time will be guaranteeing lag
Click to expand...

The maximum user count is one million (after which more hardware and additional routes need to be added) and your calculation discounts the fact that to reach 128 kb/s your frame size needs to be 1500 bytes and not 64 bytes. With 64 bytes all you can do is ping as you'll never get to 128 kb/s.
 
r00igev@@r said:
The maximum user count is one million (after which more hardware and additional routes need to be added) and your calculation discounts the fact that to reach 128 kb/s your frame size needs to be 1500 bytes and not 64 bytes. With 64 bytes all you can do is ping as you'll never get to 128 kb/s.
Click to expand...

But iBurst can not control packet size. The half-life 2 engine (as well as most online games I'm sure) can change the rate which you get updated over the internet. The more updates per cycle the more bandwidth it takes.

Example: Update cycle low:
1 - Every 500ms it takes how the world is and sends it to you. The data count is 1KB. ("2KB/s")
2 - Update the rate and the world to 100ms. The data count is still 1KB but it's sent more often = "10KB/s"

The data size per request hasn't increased but the throughput has.

Another interesting observation is that if you are measuring the time it takes to process deep scan on packets - you're actually slowing the process down. There are cpu cycles used to find this data, read/writes and interface lag as well. If there is non-volatile audit logs on this device [I assume it's purely hardware, software is too slow], expect the over all latency to shoot up dramatically.

But the point still stand on queuing latency.

31.18µs for stream containing 1518 byte frames.
Click to expand...

Because of queuing you can say latency increases by 1ms for every 30 odd users going at ibursts maximum speed. And the queuing compounds this over time (nature of queues - think of a post office may only take you 5mins to renew your p.o.box at the till, but it takes you 30mins to get there)

But you're correct that shaping processing shouldn't be the biggest bottle neck in the iBurst internal systems I'd say any non-volatile storage will be a bigger problem.

I have no idea how usage monitoring is done, but it would happen after shaping [cant charge for those packets being blocked right?]. Which explains why reports don't work sometimes and show 0GB. You don't want people slowing the monitoring tools down with a mass refresh usage attack and instead have a 'proxy' database.

I would also say that the monitoring tools are within iBursts server rack [because of the DC++ avoiding monitoring with some clever routing].
 
eltherza said:
Another interesting observation is that if you are measuring the time it takes to process deep scan on packets - you're actually slowing the process down. There are cpu cycles used to find this data, read/writes and interface lag as well. If there is non-volatile audit logs on this device [I assume it's purely hardware, software is too slow], expect the over all latency to shoot up dramatically.
Click to expand...
The latency is measure using external testers.
But the point still stand on queuing latency.
Click to expand...
You are becoming confused between a monolithic general purpose multi-processor and a dedicated custom ASIC. These devices are ethernet switches with additional ASICS strapped. These devices do not delay packets any more or less than any other ethernet switch. The difference between a multiprocessor and a dedicated ASIC is exponentially large, as an example, the bomb used to decode the nazi enigma codes during WWII was able to do it faster than a current day program written on a modern laptop.
I have no idea how usage monitoring is done, but it would happen after shaping [cant charge for those packets being blocked right?]. Which explains why reports don't work sometimes and show 0GB. You don't want people slowing the monitoring tools down with a mass refresh usage attack and instead have a 'proxy' database.
Click to expand...
The web site show 0GB due to poor web programming and development.
I would also say that the monitoring tools are within iBursts server rack [because of the DC++ avoiding monitoring with some clever routing].
Click to expand...
I don't understand?
 
r00igev@@r said:
The latency is measure using external testers.
Click to expand...

We know the the measuring of these things via electrical means is very hard to do to be accurate. If you are measuring from an external source, then I doubt the results very much. If the device timestamps in and timestamps out essentially the device is measuring the time

You are becoming confused between a monolithic general purpose multi-processor and a dedicated custom ASIC. These devices are ethernet switches with additional ASICS strapped. These devices do not delay packets any more or less than any other ethernet switch. The difference between a multiprocessor and a dedicated ASIC is exponentially large, as an example, the bomb used to decode the nazi enigma codes during WWII was able to do it faster than a current day program written on a modern laptop.
Click to expand...

Much like a PPU or GPU. But lets go back Bombe for second. Here is a wiki quote:
"when the time to set up and run through all 17,576 possible positions for one rotor order was about 20 minutes"

Thats 26x26x26. Do you know that my laptop, running very slow java, can go through 26x26x26x26x26x26 (308915776 iterations) in about the same time?

I don't understand?
Click to expand...

I've said to much, nevermind.
 
eltherza said:
Much like a PPU or GPU. But lets go back Bombe for second. Here is a wiki quote:
"when the time to set up and run through all 17,576 possible positions for one rotor order was about 20 minutes"
Thats 26x26x26. Do you know that my laptop, running very slow java, can go through 26x26x26x26x26x26 (308915776 iterations) in about the same time?
Click to expand...
Proves the point. Do you have a java program that does the same? 99% of the java iterations are for it to manage itself.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X