in a recent discussion about accurate one-way latency measurements in data centers, it was asked "why not use GPS?" (instead of PTP for example) - the rationale being every smart phone has GPS in so it must be cheap...
at first blush, this sounds plausible, given the pervasiveness of GPS (G=Global) and decent accuracy, so I started to come up with a (long) list of reasons why it isn't (plausible) - starting from
1. you're indoors.
no reception -
ok, so a) run an antennae from the roof of the building down to each rack, and re-dist across the systems in the rack
or b) have one receiver and re-broadcast the radio signal in the server rooms and have an antennae on every rack or system
2. distributed antennae
a) need to calibrate the latency of the signal over the roof to each system + significant wiring cost
b) re-broadcast could cause significant interference, plus the racks themselves would cause massive multi-path problems - since they're stationary could obviously calibrate for that....
note you need to have sight of enough satellites at any given time to get reliable signal, plus they are not actually 100% reliable anyhow....
3. What about re-distributing the GPS received data in packets (ideally as part of ethernet pre-amble)
So you still now have all the packet delay variance/jitter you had to solve with PTP (or NTP in the old days) and estimating that was the whole point of PTP - GPS is just one source - just have a local accurate master clock on some systems in the data center is fine and dandy
4. cost
phone GPS is actually Assisted GPS usually and not very accurate - indeed, even outdoors, mult-path (reflections off buildings) disrupts things sufficiently that most navigation systems resort to accelerometers, gyros and maps to validate (or rule out) received clock/location data. Also the signals need to be cross checked against Ephemeris data, which is 50k of info about where the satellites orbits take them. real precision GPS (satnav in planes/boats) is not cheap in fact.
that'll do for now
at first blush, this sounds plausible, given the pervasiveness of GPS (G=Global) and decent accuracy, so I started to come up with a (long) list of reasons why it isn't (plausible) - starting from
1. you're indoors.
no reception -
ok, so a) run an antennae from the roof of the building down to each rack, and re-dist across the systems in the rack
or b) have one receiver and re-broadcast the radio signal in the server rooms and have an antennae on every rack or system
2. distributed antennae
a) need to calibrate the latency of the signal over the roof to each system + significant wiring cost
b) re-broadcast could cause significant interference, plus the racks themselves would cause massive multi-path problems - since they're stationary could obviously calibrate for that....
note you need to have sight of enough satellites at any given time to get reliable signal, plus they are not actually 100% reliable anyhow....
3. What about re-distributing the GPS received data in packets (ideally as part of ethernet pre-amble)
So you still now have all the packet delay variance/jitter you had to solve with PTP (or NTP in the old days) and estimating that was the whole point of PTP - GPS is just one source - just have a local accurate master clock on some systems in the data center is fine and dandy
4. cost
phone GPS is actually Assisted GPS usually and not very accurate - indeed, even outdoors, mult-path (reflections off buildings) disrupts things sufficiently that most navigation systems resort to accelerometers, gyros and maps to validate (or rule out) received clock/location data. Also the signals need to be cross checked against Ephemeris data, which is 50k of info about where the satellites orbits take them. real precision GPS (satnav in planes/boats) is not cheap in fact.
that'll do for now
No comments:
Post a Comment