IQ of onlive!!

[taltamir]

A ping is too and from.
A sends a packet to B
B recieves packet and sends reply back.
So you need to double the distances/time.

Good point. But even multiplying it by 2 it doesn't account for it.

@dissection. You merely went and wrote the locations of each hop and that it doesn't add latency. But this wasn't my question. My question was what do each of the columns mean... AFAIK column 1 is how many hops were already passed. Cloumns 2-4 are a ms number, I have no idea what it measures. Column 5 is the address of the next hop.
What do columns 2-4 measure.
Telling me the location of each address (which I could already tell) doesn't help.

I decided to ask wikipedia: http://en.wikipedia.org/wiki/Traceroute

So columns 2-4 are for 3 separate packets with the same TTL. Note that they are not related. That is, the 3 values in columns 2-4 of row 1 are the time it took each of the 3 packets sent with TTL of 1 to reach the first point and for an ICMP packet to be generated and returned to me.
But the 3 ms values in ms for 3 entirely different packets, sent later with a TTL of 2.

Effectively you are pinging each individual step. This does allow you to make some calculations though. telling us how much delay was introduced by the actual routers. Proof of its existance is in your own traceroute.

5 95 ms 107 ms 94 ms xe-7-0-0.cr1.nyc3.us.nlayer.net [69.22.142.30]
Notice the pings go up...moving from the UK to the US
6 100 ms 100 ms 99 ms xe-2-0-0.cr1.iad1.us.nlayer.net [69.22.142.92]
Moving in the US

As you can see, sending 3 packets with a TTL of 5, effectively pinging the 5th hop (telling you round trip time to the 5th hop) took 95ms, 107ms, and 94ms.
The speed of light did NOT fluctuate between the three. The reason for the difference between the 94ms and 107ms one is purely due to delay introduced by the routing equipment or your own computer.
Note that the 6th hop had pings of 100, 100, and 99ms. Note that they are all actually below the 107, but higher then the 94 and 95 ones. It is at a longer distance, yet produced less delay then a shorter distance on occasion (due to congestion?), yet usually it produces a 5ms longer trip.

You can calculate the time it will take light to transverse the distance between england and Denmark for example, calculate the difference between the pings of the england and denmark hops (its average that is), divide that by two, and subtract the time it would have taken light to travel to get the delay. But frankly, that would have only been useful had all 3 values been completely identical. With them fluctuating this much its completely obvious that there is delay; and the math I proposed above will not be accurate (since its comparing different packets; not the same packet).

 

[Lonbjerg]

Good point. But even multiplying it by 2 it doesn't account for it.

@dissection. You merely went and wrote the locations of each hop and that it doesn't add latency. But this wasn't my question. My question was what do each of the columns mean... AFAIK column 1 is how many hops were already passed. Cloumns 2-4 are a ms number, I have no idea what it measures. Column 5 is the address of the next hop.
What do columns 2-4 measure.
Telling me the location of each address (which I could already tell) doesn't help.

I decided to ask wikipedia: http://en.wikipedia.org/wiki/Traceroute

So columns 2-4 are for 3 separate packets with the same TTL. Note that they are not related. That is, the 3 values in columns 2-4 of row 1 are the time it took each of the 3 packets sent with TTL of 1 to reach the first point and for an ICMP packet to be generated and returned to me.
But the 3 ms values in ms for 3 entirely different packets, sent later with a TTL of 2.

Effectively you are pinging each individual step. This does allow you to make some calculations though. telling us how much delay was introduced by the actual routers. Proof of its existance is in your own traceroute.



As you can see, sending 3 packets with a TTL of 5, effectively pinging the 5th hop (telling you round trip time to the 5th hop) took 95ms, 107ms, and 94ms.
The speed of light did NOT fluctuate between the three. The reason for the difference between the 94ms and 107ms one is purely due to delay introduced by the routing equipment or your own computer.
Note that the 6th hop had pings of 100, 100, and 99ms. Note that they are all actually below the 107, but higher then the 94 and 95 ones. It is at a longer distance, yet produced less delay then a shorter distance on occasion (due to congestion?), yet usually it produces a 5ms longer trip.

You can calculate the time it will take light to transverse the distance between england and Denmark for example, calculate the difference between the pings of the england and denmark hops (its average that is), divide that by two, and subtract the time it would have taken light to travel to get the delay. But frankly, that would have only been useful had all 3 values been completely identical. With them fluctuating this much its completely obvious that there is delay; and the math I proposed above will not be accurate (since its comparing different packets; not the same packet).

You to take into account that a core-router has pings and trace as VERY low priority.
It handlles the packte traffic and when it has ilde time it repplies on ping/traces, that is why the number fluctuates.
And why you look at the first number (the "norm")

This is from a customers router (running ADSL2+)

fullrate> ip traceroute [URL="http://www.anandtech.com/"]www.anandtech.com[/URL]
Resolving [URL="http://www.anandtech.com/"]www.anandtech.com[/URL]... traceroute to [URL="http://www.anandtech.com/"]www.anandtech.com[/URL] (208.65.201.105)
 30 hops max, 40 byte packet
  1:xxx.xxx.xxx.xxx  (50 ms) (20 ms) (20 ms)
  2:90.185.4.217  (v243-cosw1-ar.fullrate.dk) (20 ms) (20 ms) (20 ms)
  3:195.215.109.205  (te2-2.arcnxc7.dk.ip.tdc.net) (20 ms) (20 ms) (20 ms)
  4:83.88.13.5  (pos6-0-0.ldn2nxg2.uk.ip.tdc.net) (50 ms) (40 ms) (50 ms)
  5:195.66.226.37  (xe-3-0-0.cr1.lhr1.uk.nlayer.net) (40 ms) (40 ms) (50 ms)
  6:69.22.142.9  (xe-2-2-0.cr1.nyc3.us.nlayer.net) (120 ms) (130 ms) (120 ms)
  7:69.22.142.92  (xe-2-0-0.cr1.iad1.us.nlayer.net) (130 ms) (130 ms) (130 ms)
  8:69.31.31.178  (ae1-40g.ar1.iad1.us.nlayer.net) (130 ms) (130 ms) (130 ms)
 
*snip*

Notice the 20 ms at the first hop?
That was the xDSL lantency from IAD(router) to DSLAM

But notice that even if we route from hop 2 to 3, the lantency don't go up, because the geopgrahical distance is miniscule.

The biggest step in lantency is then:

From IAD to DSLAM (hop 1) 20ms added
From DK to UK (hop 4) 30ms added
From UK to US (hop 6) 80ms added

At total of 130ms added from geographical distance.
Now if we ping from the same router, we get this:

fullrate> ip ping [URL="http://www.anandtech.com/"]www.anandtech.com[/URL]
Resolving [URL="http://www.anandtech.com/"]www.anandtech.com[/URL]... 208.65.201.105
      sent      rcvd  rate    rtt     avg    mdev     max     min
         1         1  100     130     130       0     130     130
         2         2  100     120     129       3     130     120
         3         3  100     120     128       5     130     120

The lantecy is added via distance...not routing.

Hope that helped.

 

[taltamir]

the latency is added from both, obviously. SOME routers will not add noticeable latency as you have shown going from hop 2 to 3; some would.

take From DK to UK (hop 4) 30ms added. 30ms added to a round trip is 15ms added in each direction.

distance between UK and denmark: http://www.mapcrow.info/Distance_between_London_UK_and_Copenhagen_DA.html
955 161.757 meters

@ 66% of c it will take light 4.7791150086237326223863843832923 ms to travel that distance. Aka 4.8ms in each direction. However, the total time it took was 15ms in each direction, 3 times that.

So while your neighborhood switch managed to move the data at under 0.5ms (rounding made it go away to 0ms), the uk to dk round trip took about 10ms for the light and 20ms for the routers.

PS. you have certainly taught me much here, and made me look up more data and teach myself. note that I concede my initial point was wrong. time for light to travel is not irrelevant. However, it seems to be about 1/3 of the actual time according to current calculations based on all the examples given in this thread. meaning routing still accounts for a good 2/3 of the time.

 

[Voo]

As you can see, sending 3 packets with a TTL of 5, effectively pinging the 5th hop (telling you round trip time to the 5th hop) took 95ms, 107ms, and 94ms.
The speed of light did NOT fluctuate between the three. The reason for the difference between the 94ms and 107ms one is purely due to delay introduced by the routing equipment or your own computer.

Um yeah, there's absolutely no way that the 2nd package could've taken another way - after all we know that the internet isn't a mesh of any kind but just some straight forward connections

You can reduce latency of stations by using cut through instead of store and forward for example, but you'll always be limited by the propagation delay of the materials you're using which is at least .6c for copper or to put it mathematically the delay will always be length / speed of the medium. If we assume the ~.6c for copper (that's more of an lower bound, but it'll do), we get around 5.5ms delay per 1000km distance.
So while the processing delay is constant, the propagation delay grows linearly by distance and honestly processing packages doesn't take much time, that's really not the bottleneck here.
Actually there are lots of things that affect the latency (mostly transfer speed, propagation delay, processing delay, bit rate of the cable [something where transfer speed obviously also plays a role], some things obviously for sender as well as receiver if we consider RTT..)

And you can't just measure 3 packages and then make a valid statement, there are so many variables (for long ways chances are good that packages will use different paths, you don't know utilization of the paths and equipment,..) you don't know that can affect the results, you could just as well throw a coin to decide.

PS: Oh and don't forget that cables certainly are NOT routed directly from one country to the other, since you don't even know the route the package took, it gets rather complex to make certain statements.. well that's in the nature of the beast.

 

[Lonbjerg]

Um yeah, there's absolutely no way that the 2nd package could've taken another way - after all we know that the internet isn't a mesh of any kind but just some straight forward connections

You can reduce latency of stations by using cut through instead of store and forward for example, but you'll always be limited by the propagation delay of the materials you're using which is at least .6c for copper or to put it mathematically the delay will always be length / speed of the medium. If we assume the ~.6c for copper (that's more of an lower bound, but it'll do), we get around 5.5ms delay per 1000km distance.
So while the processing delay is constant, the propagation delay grows linearly by distance and honestly processing packages doesn't take much time, that's really not the bottleneck here.
Actually there are lots of things that affect the latency (mostly transfer speed, propagation delay, processing delay, bit rate of the cable [something where transfer speed obviously also plays a role], some things obviously for sender as well as receiver if we consider RTT..)

And you can't just measure 3 packages and then make a valid statement, there are so many variables (for long ways chances are good that packages will use different paths, you don't know utilization of the paths and equipment,..) you don't know that can affect the results, you could just as well throw a coin to decide.

PS: Oh and don't forget that cables certainly are NOT routed directly from one country to the other, since you don't even know the route the package took, it gets rather complex to make certain statements.. well that's in the nature of the beast.

As we like to joke about on the job..."it's the curvature of the earth".

And yes, I have never seen straight lines of fiber, looking at a map of our backbone right now...not a single straight line in sight, here is a picture:





As said, thinking you can take c x distance = lantency is very naive

 

[taltamir]

Um yeah, there's absolutely no way that the 2nd package could've taken another way - after all we know that the internet isn't a mesh of any kind but just some straight forward connections

It is possible that they took another path, but if that is the case then the entire premise behind trace-route is wrong, flawed, and makes the tool useless. I rather doubt that is the case, but I do not have sufficient expertise to say if it is or isn't so.

The internet is indeed a mesh, but it should be consistent. each router should decide to sent a packet with the same info at the same route every time, unless something in its routing tables was changed. It is highly unreasonable to assume such a change occurred between packet 1 and 2, then occurred again between packet 2 and 3.

PS: Oh and don't forget that cables certainly are NOT routed directly from one country to the other, since you don't even know the route the package took, it gets rather complex to make certain statements.. well that's in the nature of the beast.

While they do not go in a perfect straight line, we know for a fact it went via one cable between those with no intermediary routers (maybe a repeater, but not a router). thanks to TTL. So there is in fact a direct cable from DK to UK. While it does not go in a straight line, to say it is slightly more then 3 times the length of the distance between the two (based on my calculations from before) is going too far.



Not straight lines, but they aren't looping so badly as to be a length slightly greater than 3x the distance between any routing points either.

 

[aggressor]

Where are the current datacenters located? Anyone have an address for them so I can check my latency?

 

[busydude]

Where are the current datacenters located? Anyone have an address for them so I can check my latency?

Using wireshark I got 74.85.146.34 for onlive. Located in Nebraska. That may well be the mid west data center.

 

[Voo]

It is possible that they took another path, but if that is the case then the entire premise behind trace-route is wrong, flawed, and makes the tool useless. I rather doubt that is the case, but I do not have sufficient expertise to say if it is or isn't so.

The internet is indeed a mesh, but it should be consistent. each router should decide to sent a packet with the same info at the same route every time, unless something in its routing tables was changed. It is highly unreasonable to assume such a change occurred between packet 1 and 2, then occurred again between packet 2 and 3.

That's only true if you use static routing, which I think we can with almost certainity disqualify - that doesn't even work for medium sized companies. No there are some rather intriguing (well actually the principles are easy; look for floyd-warshall for example) dynamic routing algorithms at work and depending on the current load on the different paths the router may indeed pick a different route everytime you send a package and you can't do anything about since it's out of your reach. Does that mean trace routing is flawed? Well to a certain degree sure, but it's the best you've got and you can make statements about the whole from a statistical standpoint (so for a few thousand packages you may still be able to make a valid statement).
And sure it's not 3times the distance, but with only a few packages there could be many reasons for the delays, make the same for a few thousand packages, compute median, variance and mean and we could get a clearer picture. But yeah it could be some slow routher that's the problem here, not saying the opposite

 

[taltamir]

That's only true if you use static routing, which I think we can with almost certainity disqualify - that doesn't even work for medium sized companies. No there are some rather intriguing (well actually the principles are easy; look for floyd-warshall for example) dynamic routing algorithms at work and depending on the current load on the different paths the router may indeed pick a different route everytime you send a package and you can't do anything about since it's out of your reach. Does that mean trace routing is flawed? Well to a certain degree sure, but it's the best you've got and you can make statements about the whole from a statistical standpoint (so for a few thousand packages you may still be able to make a valid statement).

If this is true to the extent you say then traceroute is completely and utterly worthless and tells us absolutely nothing.

And sure it's not 3times the distance, but with only a few packages there could be many reasons for the delays, make the same for a few thousand packages, compute median, variance and mean and we could get a clearer picture. But yeah it could be some slow routher that's the problem here, not saying the opposite

It could be, I myself and trying to figure it out. My first claim was that the speed of light is so great that it is irrelevant to the discussion entirely and I proved myself wrong as soon as I did the math
So far, as I understand it, we have:
1. Some delay due to speed of light.
2. Some delay due to packet processing in origin and destination (aided by offloading to specialized hardware)
3. Some delay due to wires not being straight lines
4. Some delay due to routers
5. Some delay due to occasionally packets being sent via a different route that is not the shortest route to the target.

 

[Voo]

It could be, I myself and trying to figure it out. My first claim was that the speed of light is so great that it is irrelevant to the discussion entirely and I proved myself wrong as soon as I did the math
So far, as I understand it, we have:
1. Some delay due to speed of light.
2. Some delay due to packet processing in origin and destination (aided by offloading to specialized hardware)
3. Some delay due to wires not being straight lines
4. Some delay due to routers
5. Some delay due to occasionally packets being sent via a different route that is not the shortest route to the target.

Well I think that picture could help: http://img43.imageshack.us/i/rtto.png/

Legend (the original slide was sadly in german, but I think my translation isn't that bad):
1. delay due to signal propagation - cable length / signal speed
2. delay due to transfer of data - bits in package / bitrate
3. precession delay of the received data - cpu usage of device, what does it have to do with it?
4. delay till data can be sent - depends on the utilization of the link, how fast can the link send queued data
5. the same as 2, but this time for the receiver

So you can use better material to affect 1, but that's usually out of question, 3 should be rather short for stuff like pings (but if you want some data from a DB where the receiver has to look it up, process it, etc. it can be the dominating factor), 4 statistically depends on the utilization of the link.
The real optimization potential lies in 2/5.. instead of waiting for the whole data to arrive, you continue to send the data as soon as you're sure that there was no collision (we're simplifying here [late collisions for example are conveniently ignored], but it's almost true ): http://img514.imageshack.us/i/stfct.png/

Hope that helps to get some feeling how that stuff works and how latency is "put together", the usual disclaimer: everything is simplified, I'm no expert in that area and my lectures about that stuff were a long time ago - so if someone has objections, just say something.. but all in all I think it's a not too bad overview, at least I hope

PS: And I really got to thank you, a small refresher about networking can't harm and trying to explain something, is really the best way to understand it better yourself (well the looking up the slides didn't harm either )

 

[taltamir]

3. precession delay of the received data - cpu usage of device, what does it have to do with it?

According to the anandtech article which I linked, using offloading cards improved latency from 110 to 80 in their particular test.
so clearly using a NIC that can process the packets faster improves performance.

 

[Skurge]

Uh guys, all this network talk is great, but you guys are horribly off-topic.

 

[Lonbjerg]

Uh guys, all this network talk is great, but you guys are horribly off-topic.

Actually networking is vital to understanding OnLive as input lag will make or breake OnLive.

 

[Lonyo]

Actually networking is vital to understanding OnLive as input lag will make or breake OnLive.

Yeah but is it relevant in a video card and graphics thread?
Maybe in PC Gaming or Networking it might be more relevant, but this was (at least the main thrust) about graphics (based on the OP). Hence the topic, "IQ of OnLive".

Also, OnLive doesn't support WiFi, because of lag issues.
http://forums.anandtech.com/showthread.php?t=2057457
At the end of this thread it's currently a network/lag/wifi/etc discussion, and such discussion might be more relevant there than in this forum.
Not that this place really ever sticks on topics.

 

[Lonbjerg]

Yeah but is it relevant in a video card and graphics thread?
Maybe in PC Gaming or Networking it might be more relevant, but this was (at least the main thrust) about graphics (based on the OP). Hence the topic, "IQ of OnLive".

Also, OnLive doesn't support WiFi, because of lag issues.
http://forums.anandtech.com/showthread.php?t=2057457
At the end of this thread it's currently a network/lag/wifi/etc discussion, and such discussion might be more relevant there than in this forum.
Not that this place really ever sticks on topics.

Kinda hard to seperate OnLive (and it's I.Q.) from lanctency/bandwith...I suppose you could say that OnLive is more Network/Encoding -> Graphics...than the usual Hardware/Software -> Graphics that we are used to.

 

[Borealis7]

OnLive is OK for a first generation service/technology. there will be better attempts at it either by this company or by others and i still believe this is the future of gaming if its to stay economical and fight piracy.

so for the first generation, don't play FPSs. play Turn Based games, play RTSs maybe SC2 because it wont have cutting edge graphics, play adventure games, etc. eventually the technology will catch up.

last year i was interviewed for a programming job at a company which was developing a similar type of service. i had heard about OnLive and i thought about it myself as i believe in this system. i asked them about input lag, about FPSs and the guy said they had solved these major problems but were working on the service from a different angle (he obviously couldn't tell me more).

 

[taltamir]

part of onlive's reduced quality is their real time compressive of the video; which is partially due to network (they must compress it quickly to avoid latency, and they must compress it at lower quality to meet their target goal of 5mbps).
I have recently read a very awesome article that was released when onlive first came about.
http://www.eurogamer.net/articles/gdc-why-onlive-cant-possibly-work-article

you should read it, it is fascinating. btw, I bet I know who the world expert who helped youtube go HD and does most of the work on the world's best compression codec is

 

[Ben90]

Nebraska seems like a very odd place to put a datacenter in which latency will make or break your business.

I have a question for Lonbjerg: How much latency is added by repeaters? I bet this is what adds the most latency for long distance travel.

 

[Lonbjerg]

Nebraska seems like a very odd place to put a datacenter in which latency will make or break your business.

I have a question for Lonbjerg: How much latency is added by repeaters? I bet this is what adds the most latency for long distance travel.

On a fiber-backbone?
No more than 5ms (MAXIMUM) from here to anandtech..and that is being generous, but compared to the distance, the delay is virtually negligible and not a factor I would consider.

There is a vast difference between a fiber-"repeater" and e.g. a class I/class II Ethernet Repeater.

 

[cbn]

So the first thing I did was to compare the IQ of games. I know the games usually played at 720p but I was not sure of the quality settings. After playing the demos and looking at the game, I can say that the Image quality is abysmal.

Dirt 2: FPS was very low, not playable even encountered severe stutters. Uses Dx9 and audio stutters sometimes.

I think it will be interesting to see how "Cloud Rendering" pans out against cheap, maybe even "dockable" Mobile platforms capable of Rendering directly on the device.

In one article I read the author claimed Snapdragon's AMD GPU was in some ways more powerful than a Nintendo Wii.

 

[cbn]

OnLive is OK for a first generation service/technology. there will be better attempts at it either by this company or by others and i still believe this is the future of gaming if its to stay economical and fight piracy.

I think Piracy is a real issue, but what about so called "free games" involving micro payments as a way of fighting piracy? Nexon is one company that does this.

 

[cbn]

http://www.dailytech.com/MIT+Breakthrough+Could+Make+Internet+1000+Times+Faster/article18913.htm

Will this kind of technology help make 3D Cloud rendering economical enough to compete with other business models involving 3D hardware at the client level?

 

[taltamir]

On a fiber-backbone?
No more than 5ms (MAXIMUM) from here to anandtech..and that is being generous, but compared to the distance, the delay is virtually negligible and not a factor I would consider.

There is a vast difference between a fiber-"repeater" and e.g. a class I/class II Ethernet Repeater.

if they don't care about that extra latency, why do they collocate?

 

[Ben90]

http://www.dailytech.com/MIT+Breakthrough+Could+Make+Internet+1000+Times+Faster/article18913.htm

Will this kind of technology help make 3D Cloud rendering economical enough to compete with other business models involving 3D hardware at the client level?

That article is an absolute joke, it belongs on The Onion. Whoever allowed that page to be put up has some explaining to do.

No shit direct routing is going to be faster. Unfortunately it makes no sense economically. Let me use my barely-passed-by-cheating-highschool education to write a much better and more to the point article:


Insane Internet Breakthrough!!! Quadrouple Speeds Increases!!!
The University of no-shit-sherlock has discovered that if every ISP everywhere bought four times their routers and laid four times their cables internet throughput increases a staggering 400%. The expert team led by Ben90 also discovered how to use static routing on their routers by typing in:
router(config)# ip route x.x.x.x x.x.x.x x.x.x.x x.x.x.x
This previously unheard of command basically does the exact same shit the recent M.I.T. breakthrough suggested. The future looks bright.



[/code]

if they don't care about that extra latency, why do they collocate?

I believe Lonbjerg was answering my question to the added delay from repeaters, which is basically negligible. The distance still accounts for most of the latency which is why Onlive need to collocate to keep response times low.