Hi,
On Sat, Jan 14, 2017 at 1:30 AM, walter shawlee 2 wrote:
> While probably not tight enough for time nuts use, there is a new WiFi
> technology shown at CES that provides time sync between nodes to allow audio
> to be simulcast over many locations. the info (in short form) is here for
> those
Sonos and I guess their competitors do this by dropping WiFi
compatibility. They exist on their own network in the same ISM band
so I wonder how well they coexist with WiFi. Online reports say
poorly under crowded band conditions.
On Sun, 15 Jan 2017 09:50:05 -0500, you wrote:
>Hi
>
>The push b
Modern systems are very aggressive about DVFS (dynamic voltage and
frequency scaling) so it would not surprise me at all. I have run
across this problem on the timescale of one second even on 10 year old
desktop hardware.
On Sun, 15 Jan 2017 09:32:56 -0500, you wrote:
>Hi
>
>Id be surprised if
Hi Bob,
Below are some efforts to reduce buffering in both routers and non router
network stacks including wifi. They are focusing on reducing latency -
maybe some is relevant for you.
https://www.bufferbloat.net/projects/make-wifi-fast/wiki/
https://wiki.openwrt.org/doc/howto/sqm
https://www.buf
Hi
The push behind this is whole house audio. These guys want to be able to set up
WiFi
speakers / mic's all through a home and get proper audio imaging in each room.
They likely
also want to use it to figure out which mic you are talking to using time of
arrival. They very
much want to do thi
On 1/15/17 6:27 AM, Bob Camp wrote:
Hi
Again, this is why the interest in “how the heck did they accomplish it?
With the claim of microsecond level performance, they must have run
into all these issues.
or is it "with these two specific WiFi adapters in this specific
environment, we were abl
Hi
I’d be surprised if a laptop running on wall power and doing a variety of low
level
traffic every second is throttling the chip set. It *is* doing something weird
and
that certainly is one candidate. I’m not quite as concerned with the *why* the
bumps
occur (though I am curious). I’m more
Hi
Again, this is why the interest in “how the heck did they accomplish it?
With the claim of microsecond level performance, they must have run
into all these issues.
Just a note: any time I want to do anything that matters, I put it on 5 GHz.
There are still issues, but not quite as many
Bob, I think you are pushing me in this direction, but it was my conclusion
before this discussion even began.
Most consumer WiFi devices will quiesce the WiFi chipset between major
consumer-initiated usages for battery savings, so it's not surprising to
see a good amount of random variation in pi
I haven't read the entire thread, but this may be relevant. If not, you
know where to find the delete key.
I live in a life care community - one of 450 people in 300 apartments on
3 floors. When I moved in a year ago, I could get Internet from the
house cable, and they provided the modem. I boug
Yes, it will be interesting to see how well wifi rtt/tof does indoors with
plenty of multipath. But for sure sub microsecond.
On Sat, Jan 14, 2017 at 6:32 PM Bob Camp wrote:
> Hi
>
>
>
>
>
> > On Jan 14, 2017, at 5:29 PM, Scott Stobbe
> wrote:
>
> >
>
> > I don't think wifi is ever going to be
On 1/14/17 4:25 PM, Bob Camp wrote:
Hi
Maybe the magic stamping has been hiding in the chips all along.
What’s pretty clear is that if it’s there, it’s well hidden ….
or totally unstandardized - it might be one of those "we put it in for
manufacturing test" features, and everyone does it diffe
Hi
Maybe the magic stamping has been hiding in the chips all along.
What’s pretty clear is that if it’s there, it’s well hidden ….
Bob
> On Jan 14, 2017, at 7:04 PM, jimlux wrote:
>
> On 1/14/17 3:32 PM, Bob Camp wrote:
>> Hi
>>
>>
>>> On Jan 14, 2017, at 5:29 PM, Scott Stobbe wrote:
>>>
On 1/14/17 3:32 PM, Bob Camp wrote:
Hi
On Jan 14, 2017, at 5:29 PM, Scott Stobbe wrote:
I don't think wifi is ever going to be a real-time system, as it shares the
ether with all other ISM devices. That said even 1 ms of variation is still
4 orders of magnitude greater than the actual time o
Hi
> On Jan 14, 2017, at 5:29 PM, Scott Stobbe wrote:
>
> I don't think wifi is ever going to be a real-time system, as it shares the
> ether with all other ISM devices. That said even 1 ms of variation is still
> 4 orders of magnitude greater than the actual time of flight.
>
> The precision
I don't think wifi is ever going to be a real-time system, as it shares the
ether with all other ISM devices. That said even 1 ms of variation is still
4 orders of magnitude greater than the actual time of flight.
The precision time aspect will most certainly be done in hardware, even if
it's just
Hi
Here’s what I am seeing:
64 bytes from 192.168.2.2: icmp_seq=3700 ttl=64 time=5.025 ms
64 bytes from 192.168.2.2: icmp_seq=3701 ttl=64 time=4.579 ms
64 bytes from 192.168.2.2: icmp_seq=3702 ttl=64 time=1.511 ms
64 bytes from 192.168.2.2: icmp_seq=3703 ttl=64 time=1.601 ms
64 bytes from 192.168
kb...@n1k.org said:
> Ok, what I see is that every few hours, I get a ârogue delayâ on a single
> ping. How would NTP help me spot a single transit with a 250 ms round trip
> and identify the time it occured? Keep in mind that NTP is going to
> throttle back to a very low level of âchatâ
Sorry as this is perhaps a bit off topic but I've tried to make this somewhat
time nuts relevant.
Over the years I found ping tests have worked quite well (at least on WAN
links) to roughly measure network bandwidth. When I used to visit remote sites
with WAN links I would often perform severa
I merely used the ping to demonstrate Wireshark's packet time stamping
(though in this case, it seems that the router responds immediately).
FWIW, a couple of NTP packets got captured too with a 34 ms round trip. I
was actually looking for an ARP request/response in consecutive packets on
the grou
Hi
> On Jan 14, 2017, at 1:38 PM, Chris Albertson
> wrote:
>
> On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp wrote:
>
>> Hi
>>
>> Ok, what I see is that every few hours, I get a “rogue delay” on a single
>> ping. How
>> would NTP help me spot a single transit with a 250 ms round trip and
>> ide
Hi
The issue with using Wireshark is that it still is looking at a ping. It may
tag the
event to one more digit, but all of the earlier mentioned issues with pings are
still there. Simply put, they aren’t the greatest thing for testing timing.
Bob
> On Jan 14, 2017, at 1:51 PM, Orin Eman wrot
You could run a network monitor, Wireshark for example...
https://wiki.wireshark.org/CaptureSetup/WLAN
There are specialized WIFI capture programs, but they tend to be designed
to break into networks rather than monitor performance - kismet/kismac. I
run them every so often to check for malfeasa
On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp wrote:
> Hi
>
> Ok, what I see is that every few hours, I get a “rogue delay” on a single
> ping. How
> would NTP help me spot a single transit with a 250 ms round trip and
> identify the
> time it occured? Keep in mind that NTP is going to throttle back
Hi
> On Jan 14, 2017, at 12:44 PM, jimlux wrote:
>
> On 1/14/17 8:35 AM, Bob Camp wrote:
>> Hi
>>
>
>>
>> I also believe that ping data is one way to come up with an upper bound on
>> just how awful WiFi timing can be. If others have a similar single shot
>> measure
>> of WiFi round trip th
On 1/14/17 8:35 AM, Bob Camp wrote:
Hi
I also believe that ping data is one way to come up with an upper bound on
just how awful WiFi timing can be. If others have a similar single shot measure
of WiFi round trip that can be run on a wide range of devices, I’d certainly be
just
as interest
Hi
We have a double issue here:
1) It’s a problem because “not enough information was given"
2) It’s a problem because “we are talking about it to much”
Sorry, but there is absolutely no way at all both of those criteria can
be met by me.
I do believe that WiFi time protocols are an on topic
On 1/14/17 7:53 AM, John Hawkinson wrote:
I tried to engage with you off-list and give you some pointers on this, but
that does not seem to be working. Consumer wifi driver problems are manifestly
inappropriate for this list, and trying to do both at once leads to gross
confusion :( I know this
On 1/14/17 7:46 AM, Bob Camp wrote:
Hi
Ok, what I see is that every few hours, I get a “rogue delay” on a single ping.
How
would NTP help me spot a single transit with a 250 ms round trip and identify
the
time it occured? Keep in mind that NTP is going to throttle back to a very low
level
of
This has nothing to do with time-nuts, can it stop please?
[ I don't know what forum to send you to for "weird wifi problems"; there
is probably no good one, because it is a very common consumer problem :( ]
NTP was mentioned because you (Bob Camp) had not defined the problem
very well, and asked
Hi
This is very much a one laptop to one router issue. The other couple dozen
laptops
and tablets do not see an issue. The whole thing started when a series of
firmware
updates rolled through a few weeks ago. The laptop is *maybe* 12 feet from the
router.
It’s running at 5 GHz so microwaves (a
Hi
Ok, what I see is that every few hours, I get a “rogue delay” on a single ping.
How
would NTP help me spot a single transit with a 250 ms round trip and identify
the
time it occured? Keep in mind that NTP is going to throttle back to a very low
level
of “chat” quite quickly…..
While this *
If there is a modern microwave oven with a switching power supply,
or a cordless telephone around, you might want to look there.
The old linear supply ovens were easy to deal with because they
presented a strong CW signal that drifted around as voltage, load,
and temperature changed. The switcher
On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp wrote:
> Hi
>
> Ok. so I bring up NTP on the laptop against a server on the other side of
> the country and install
> NTP on the laptop. I get all of the jitter and offset of my cable modem
> plus the network
> issues between here and who know where. If I
On Fri, Jan 13, 2017 at 8:45 PM, Chris Albertson
wrote:
> Short answer: See man page for ntpq
>
> Longer...
>
> First run NTP then after some time (15 minute to an hour) at the command
> line time type "ntpq -p"
>
> "ntpq" will query NTP for timing statistics. It will report the average
> delay
On Fri, Jan 13, 2017 at 3:35 PM, Bob Camp wrote:
> Hi
>
> What standard protocol would you recommend I run from the command line on
> my computer
> to get a quick estimate of the timing lag and variablilty on my
> particular WiFi connection?
If I wanted to do this I would use MTR (it has been
> What standard protocol would you recommend I run from the command line on my
> computer to get a quick estimate of the timing lag and variablilty on my
> particular WiFi connection?
I'd use ping. But you said "quick estimate".
My wifi is crappy enough that its noise swamps everything else.
On 1/13/17 2:19 PM, Chris Caudle wrote:
On Fri, January 13, 2017 3:17 pm, Bob Camp wrote:
It just so happens that I'm trying to track down an issue with my WiFi
as I type this.
This is getting off topic for time-nuts very quickly,
well, wireless distribution of accurate time is, I think, on
On Fri, January 13, 2017 3:17 pm, Bob Camp wrote:
> It just so happens that I'm trying to track down an issue with my WiFi
> as I type this.
This is getting off topic for time-nuts very quickly, but use bufferbloat
and "make wifi fast" as search phrases. The guy who did a lot of the work
on queue
It’s a little more complicated than that. A switch’s main cpu is like a host
with rx coalesce set to 100. And there are a surprising number of things that
trigger the main cpu beyond management functions. Multicast is a good example.
The amount of load on the main cpu can be quite variable, and
Hi
It just so happens that I’m trying to track down an issue with my WiFi as
I type this. My *guess* is that there is a dropout going on. The only easy
way I can see to get a round trip time with a high data rate is to run ping.
It’s the only tool that gives me something that is fast enough to sp
To add to this I'd be curious in knowing about easy PC based ways to measure
network latencies / delays with microsecond accuracy vs millisecond accuracy.
The tools I used to use at work were generally designed for use on networks
where millisecond resolution measurements made sense as a "figure
Bob Camp wrote on Fri, 13 Jan 2017
at 15:35:19 -0500 in :
> What standard protocol would you recommend I run from the command
> line on my computer to get a quick estimate of the timing lag and
> variablilty on my particular WiFi connection?
Bob: I hope you read the whole of my message, rather t
Hi
Ok. so I bring up NTP on the laptop against a server on the other side of the
country and install
NTP on the laptop. I get all of the jitter and offset of my cable modem plus
the network
issues between here and who know where. If I want to know the specific delay
issues just
on the WiFi con
Hi
That *assumes* that NTP is installed on the laptop.
Bob
> On Jan 13, 2017, at 3:45 PM, Chris Albertson
> wrote:
>
> Short answer: See man page for ntpq
>
> Longer...
>
> First run NTP then after some time (15 minute to an hour) at the command
> line time type "ntpq -p"
>
> "ntpq" will
Short answer: See man page for ntpq
Longer...
First run NTP then after some time (15 minute to an hour) at the command
line time type "ntpq -p"
"ntpq" will query NTP for timing statistics. It will report the average
delay between the local computer and the set of reference clocks (other
server
Hi
What standard protocol would you recommend I run from the command line on my
computer
to get a quick estimate of the timing lag and variablilty on my particular
WiFi connection?
Bob
> On Jan 13, 2017, at 3:25 PM, John Hawkinson wrote:
>
> Can we please stop talking about pings?
>
> Bob
Even with the long and variable ping time, time sync can work. The reason
it can work is that time is not re-sync'd in one "ping" but time sync is an
on-going process that occurs over a period as long as hours.
Think about adjusting the rate of a clock by hand. The computer (NTP) can
(and does) u
Can we please stop talking about pings?
Bob Camp wrote on Fri, 13 Jan 2017
at 15:12:38 -0500 in :
> I’m sure you are right about the response time. Right now the
> variation is running almost 3 ms at one sigma on a ping so there is
> a lot to do simply to get the accuracy anywhere near 1 us.
Us
Hi
I’m sure you are right about the response time. Right now the variation is
running almost 3 ms
at one sigma on a ping so there is a lot to do simply to get the accuracy
anywhere near 1 us.
Bob
> On Jan 13, 2017, at 2:35 PM, Chris Caudle wrote:
>
> On Fri, January 13, 2017 11:40 am, Bob Ca
On Fri, January 13, 2017 11:40 am, Bob Camp wrote:
> The ping response is anywhere from 2 ms out to 400 ms. Most of
> the time it's in the 3 to 9 ms range. Simply taking that
> down to < 1 us would be a really big deal.
I doubt that the response time will get that low, rather the time sync
will be
Hi
I probably should have added that I already know that the switch will do sub 1
ms
LAN pings all day long with the near zero load that it’s running. Sorry about
that.
Now, there certainly are OS level things on my laptop that will muck up pings.
Unfortunately
they also get into a number of
> On Jan 13, 2017, at 09:40, Bob Camp wrote:
>
> Just for reference, I happen to be running a ping over my local WiFi to one
> of the switches
> on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of
> the time it’s
> in the 3 to 9 ms range. Simply taking that down to < 1 u
I saw this article too -- is anyone aware of something with more
technical details? For example, where in the protocol stack does it
work? Is it specific to 802.11 or general purpose ethernet?
Speaking as someone who has a primary hobby of the development of
super low cost time sync algorithms a
On Fri, January 13, 2017 10:59 am, Bob Camp wrote:
> 1588 is a "less than a microsecond" sort
> of approach that does indeed get down to nanosecond
> sort of levels. This could be similar.
There was talk of adding a wireless profile into 1588 either as an
addendum or as part of PTPv3. I suspect t
Hi
Just for reference, I happen to be running a ping over my local WiFi to one of
the switches
on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of the
time it’s
in the 3 to 9 ms range. Simply taking that down to < 1 us would be a really big
deal.
Bob
> On Jan 13, 2017
Hi
A lot depends on how much “less than a microsecond” the chip sets really
deliver in the real world. If they get down into
the sub 100 ns range (which they might), it’s a very useful thing for relaying
GPS data from a roof antenna down to an
NTP server in the basement. 1588 is a “less than a
they were really short on hard details about this new technology.
the *WiFi alliance* website only shows this off-site article link I found under
NEWS:
http://www.rcrwireless.com/20170104/test-and-measurement/20170104test-and-measurementwi-fi-alliance-to-certify-timesync-among-multiple-devices-
While probably not tight enough for time nuts use, there is a new WiFi
technology shown at CES that provides time sync between nodes to allow audio to
be simulcast over many locations. the info (in short form) is here for those
interested:
http://electronicdesign.com/embedded/upgrade-wi-fi-pr
59 matches
Mail list logo