netdev - Re: How To Temporarily Suspend Network Traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D486713.70200@hp.com>
Date:	Tue, 01 Feb 2011 12:03:31 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Volkan YAZICI <volkan.yazici@...il.com>
CC:	netdev@...r.kernel.org
Subject: Re: How To Temporarily Suspend Network Traffic

Volkan YAZICI wrote:
> On Tue, 01 Feb 2011 09:32:32 -0800, Rick Jones writes:
> 
>>Out of not quite idle curiousity, what are you trying to accomplish?
> 
> I'm trying to implement a coarse-grained soft-TDMA (Time Division
> Multiple Access) among devices in a Wi-Fi network. (Coarse-grained, that
> is, compared to a hardware implementation.) Assuming that device clocks
> are in sync via NTP, I will figure out the granularity I can achieve
> with soft-TDMA.

As in Fred gets to transmit from 0 to N, Ethel gets to transmit from N+1 to 2N 
and so on, based on absolute time?

Getting small number of microsecond synchronization between multiple systems via 
NTP (particularly if they are synchronized via a wireless network) may prove 
challenging.  At least that is my take as a member of the peanut gallery reading 
over the shoulders of the discussions that take place in comp.protocols.time.ntp

>>Instead of using tc to set a zero rate, you could perhaps try using tc
>>to set a delay? If it doesn't offer microseconds of delay, pehaps
>>setting a delay and then eliminating it after your own pause will do
>>what you want - depends of course on what it is you really want.
> 
> Thanks for the advice. I'll check this out and see what I can do.
> 
>>Your saying you wanted microsecond granularity suggests you don't want
>>to suspend traffic for very long?
> 
> I want to figure out the smallest delay that I can achieve in a periodic
> manner. (E.g., freeze the traffic for 200us, continue without
> interruption for 800us, and freeze the traffic again for another 200us,
> etc.) Pay attention that, an undeterministic delay somewhere in between
> 1000us is not something I prefer, I must be able to determine the point
> in time where delay will appear -- ofcourse, with some error margin.

Sounds, well, challenging :)  The determining the point in time part in 
particular.  One thing I've learned is that the cell towers in a cell network 
sync their time directly to GPS with some kit that is non-trivially expensive.

rick jones

> 
> 
> Regards.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html