Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: >> Rick Jones wrote: >> For anyone that cared enough about emissions, (and not about price) >> they could always get a EMSEC / TEMPEST, Level A / 1, PC. > > In one case to make it so that it does not destroy other people's enjoyment of > their system, and the other to make sure a determined adversary cannot make > use of > yours. Different boxes for different folks. Tempest is about making sure that insufficient radiation exists to be able to recover a useful signal. Normal PC screening is to prevent sufficient noise from escaping to cause problems to others. If you can recover useful information above the background noise, the machine is definitely compromising any nearby receivers. Tempest isn't about stopping people accessing your computer, although normal EMC screening is, in part, about stopping local radio transmitters upsetting the machine. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Interface restrictions confusing me
Brian Utterback wrote: > You misunderstand. David's answer has nothing to do with firewalls. The > ntpd daemon binds the addresses so that it can choose the port and > addresses to send on. I gave him the benefit of the doubt and assumed he meant that, if you are really paranoid about the port being open, you can configure your firewall to only allow traffic in for a short period after each outgoing poll. Of course, on an internal network, blocking port 123 also makes it difficult to remotely diagnose NTP problems on that machine, although you can also block such access in ntp[d].conf. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] NTP 4.2.5p232-RC Released
Redwood City, CA - 2009/10/14 - The NTP Public Services Project (http://support.ntp.org/) is pleased to announce that NTP 4.2.5p232-RC, a Release Candidate of the NTP Reference Implementation from the NTP Project, is now available at http://www.ntp.org/downloads.html and http://support.ntp.org/download. Bug Fixes: * [Bug 1337] fix incorrect args to setsockopt(fd, IP_MULTICAST_IF,...). http://bugs.ntp.org/1337 * [Bug 1339] Fix Windows-only ntp_strerror() infinite recursion. http://bugs.ntp.org/1339 * [Bug 1302] OpenSSL under Windows needs applink support. http://bugs.ntp.org/1302 * [Bug 1341] NMEA driver requires working PPSAPI #ifdef HAVE_PPSAPI. http://bugs.ntp.org/1341 Other Changes: * Update documentation for ntpq --old-rv, saveconfig, saveconfigdir, ntpd -I -L and -M, and interface/nic rules. (From Dave Hart) * Construct ntpd keyword scanner finite state machine at compile time rather than at runtime, shrink entries from 40+ to 8 bytes. The file-size of this Release Candidate is 4254286 bytes. An MD5 sum of this release is available at http://www.ntp.org/downloads.html and http://support.ntp.org/download. Please report any bugs, issues, or desired enhancements at http://bugs.ntp.org/. The NTP (Network Time Protocol) Public Services Project, which is hosted by Internet Systems Consortium, Inc. (http://www.isc.org/), provides support and additional development resources for the Reference Implementation of NTP produced by the NTP Project (http://www.ntp.org/). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Rick Jones wrote: > Uwe Klein wrote: > >>With switches the problem tends to be the strategy for handling >>(potentially) colliding traffic. >>"Passthrough", "store-and-forward", "drop/cause resend" have >>massively different transit times. >>Depending on traffic density any single switch will use a mix of all >>transfertypes. > > > I don't think it is what you meant by "drop/cause resend" but > something else "new" in 1 Gigabit Ethernet relative to old 10/100 is > support for pause and resume (moral equivalent to xon/xoff?) flow > control. No, the traffic that passes through the _switch_ hardware. if the destination port is idle you get passthrough. i.e. you get just enough bittimes delay to read the target MAC address from the paket header. if the destination port is busy you get store and forward. if the destination port is busy and local storage is full you get drop and cause resent ( certainly a low probability ) more cases if you have a speed missmatch between ports (actually the attached hosts ) then: some pakets are sent as broadcast to all ports. switches store for each port the MAC addresses seen. I have no idea if modern switches do (r)arp queries to find the port a target MAC is sitting on or just broadcast unknown MACs. All will cause unspecific delays. Hail for the times hubs were dumb repeaters with neither memory nor intelligence ;-) uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote:
> BlackLists writes:
>> For anyone that cared enough about emissions,
>> (and not about price) they could always get a
>> EMSEC / TEMPEST, Level A / 1, PC.
>
>> {I've worked on a few TEMPEST PCs (decades in the past),
>> it often takes 15 minutes of removing shielding panels
>> just to get to where you can remove the shielded container
>>a component (e.g. hard drive) is inside.
>
>
> In one case to make it so that it does not destroy other
> people's enjoyment of their system, and the other to make
> sure a determined adversary cannot make use of yours.
> Different boxes for different folks.
Both are aimed at stopping unintentional emissions.
Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ...
However weren't a few posts just complaining that those
standards were not strict enough.
TEMPEST is just stricter unintentional emission standards.
--
E-Mail Sent to this address
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote:
> E-Mail Sent to this address will be added to the BlackLists
> writes:
> >Rick Jones wrote:
> ... EMC / EMI, Unintentional / Incidental, Radiators
> >> And/or better educated customers willing and able to understand
> >> the value of a better crafted system when comparing to the one
> >> that didn't "spend the pennies."
> > For anyone that cared enough about emissions, (and not about
> > price) they could always get a EMSEC / TEMPEST, Level A / 1, PC.
> > {I've worked on a few TEMPEST PCs (decades in the past), it often
> > takes 15 minutes of removing shielding panels just to get to where
> > you can remove the shielded container a component (e.g. hard
> > drive) is inside.
> In one case to make it so that it does not destroy other people's
> enjoyment of their system, and the other to make sure a determined
> adversary cannot make use of yours. Different boxes for different
> folks.
I resisted mentioning TEMPEST since I figured it would be overkill
when perhaps just "TEAPOT" would be sufficient (perhaps one could have
an aftermarket to put a TEMPEST in a TEAPOT...)
But the main point I wanted to make was that there are several actors
involved in getting where we are today, and it isn't necessarily
_just_ the people who's emails end in .com or .gov
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Uwe Klein wrote: > then: > some pakets are sent as broadcast to all ports. > switches store for each port the MAC addresses seen. > I have no idea if modern switches do (r)arp queries to > find the port a target MAC is sitting on or just broadcast > unknown MACs. Do you mean "flood?" Broadcast implies ff:ff:ff:ff:ff:ff destination MAC. > Hail for the times hubs were dumb repeaters with neither memory nor > intelligence ;-) Indeed :) Of course, then we'd be complaining about variability in back-off times and capture effect and whatnot instead :) rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
On Wed, 14 Oct 2009 11:50:42 +0200, Uwe Klein wrote: > Rick Jones wrote: >> Uwe Klein wrote: >> >>>With switches the problem tends to be the strategy for handling >>>(potentially) colliding traffic. >>>"Passthrough", "store-and-forward", "drop/cause resend" have >>>massively different transit times. >>>Depending on traffic density any single switch will use a mix of all >>>transfertypes. >> >> >> I don't think it is what you meant by "drop/cause resend" but >> something else "new" in 1 Gigabit Ethernet relative to old 10/100 is >> support for pause and resume (moral equivalent to xon/xoff?) flow >> control. > > No, the traffic that passes through the _switch_ hardware. > > if the destination port is idle you get passthrough. > i.e. you get just enough bittimes delay to read the > target MAC address from the paket header. > I dont think many switches are passthrough nowadays. But it can be a problem that the path to the switch matix is oversubscribed. One example I know of is that on a 48 port card every 8 ports share 1Gbit to/from the backplane. Depending on the traffic by the other 7 this will create jitter. (Cisco 450x has 6*1Gbit per slot, 450xE has 8*3G per slot) /hjj ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
E-Mail Sent to this address will be added to the BlackLists
writes:
>Unruh wrote:
>> BlackLists writes:
>>> For anyone that cared enough about emissions,
>>> (and not about price) they could always get a
>>> EMSEC / TEMPEST, Level A / 1, PC.
>>
>>> {I've worked on a few TEMPEST PCs (decades in the past),
>>> it often takes 15 minutes of removing shielding panels
>>> just to get to where you can remove the shielded container
>>>a component (e.g. hard drive) is inside.
>>
>>
>> In one case to make it so that it does not destroy other
>> people's enjoyment of their system, and the other to make
>> sure a determined adversary cannot make use of yours.
>> Different boxes for different folks.
>Both are aimed at stopping unintentional emissions.
>Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ...
> However weren't a few posts just complaining that those
> standards were not strict enough.
> TEMPEST is just stricter unintentional emission standards.
Of course. That was what I said. But the purpose is different. Tempest
is to make sure that the emissions cannot be used by someone else to
determine what is going on inside your box. The other standards are to
prevent your machine from ruining other people's use of the
electromagnetic spectrum. That is a much more relaxed standard. But the
way the formal regulations are written allow one to continue emitting huge
amounts of
radiation, messing up other people's use of the radiation spectrum, as
long as it is spread around and not all emitted at some specific
frequency. Ie, the standard should probably limit the amount of
radiation emitted, not the amount emitted in some very narrow bandwidth,
or rather it should limit both.
Note that Tempest is where you want to limit the radiation and thus have
a strong incentive to make sure you emit as little as possible. The
radiation standards are where others want you to limit your radiation
and thus you have an incentive to try to find a way around the law to
save those few pennies that shielding would cost.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Rick Jones wrote: > Uwe Klein wrote: > >>then: >>some pakets are sent as broadcast to all ports. >>switches store for each port the MAC addresses seen. >>I have no idea if modern switches do (r)arp queries to >>find the port a target MAC is sitting on or just broadcast >>unknown MACs. > > > Do you mean "flood?" Broadcast implies ff:ff:ff:ff:ff:ff destination > MAC. Most certainly not. A switch (usually) forwards packets from one port to _one_ other port ( the one were the switch has seen the target MAC ) ( exempt are broadcast and multicast packets. ) Now if there is no entry for the target MAC the thing to do is either forward this packet to all ports or start a reverse arp cycle. uwe > > >>Hail for the times hubs were dumb repeaters with neither memory nor >>intelligence ;-) > > > Indeed :) Of course, then we'd be complaining about variability in > back-off times and capture effect and whatnot instead :) Someone sent me a copy of the unix haters handbook today. Nothing better than having a target for good ol bitching. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Uwe Klein wrote: > Rick Jones wrote: > > Uwe Klein wrote: > > > >>then: > >>some pakets are sent as broadcast to all ports. > >>switches store for each port the MAC addresses seen. > >>I have no idea if modern switches do (r)arp queries to > >>find the port a target MAC is sitting on or just broadcast > >>unknown MACs. > > > > > > Do you mean "flood?" Broadcast implies ff:ff:ff:ff:ff:ff > > destination MAC. > Most certainly not. > A switch (usually) forwards packets from one port to _one_ other > port ( the one were the switch has seen the target MAC ) > ( exempt are broadcast and multicast packets. ) > Now if there is no entry for the target MAC the thing to do is > either forward this packet to all ports or start a reverse arp > cycle. I don't think I've ever heard of a switch doing reverse ARP - and that would belimited to IP traffic where Ethernet carries more than just IP. Apart from that, while I think we may differ in terminology (I was tweaking on "just broadcast unknown MACs) I suspect we are in agreement on semantics. rick jones -- the road to hell is paved with business decisions... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen writes: >On Wed, 14 Oct 2009 11:50:42 +0200, Uwe Klein wrote: >> Rick Jones wrote: >>> Uwe Klein wrote: >>> With switches the problem tends to be the strategy for handling (potentially) colliding traffic. "Passthrough", "store-and-forward", "drop/cause resend" have massively different transit times. Depending on traffic density any single switch will use a mix of all transfertypes. >>> >>> >>> I don't think it is what you meant by "drop/cause resend" but >>> something else "new" in 1 Gigabit Ethernet relative to old 10/100 is >>> support for pause and resume (moral equivalent to xon/xoff?) flow >>> control. >> >> No, the traffic that passes through the _switch_ hardware. >> >> if the destination port is idle you get passthrough. >> i.e. you get just enough bittimes delay to read the >> target MAC address from the paket header. >> >I dont think many switches are passthrough nowadays. >But it can be a problem that the path to the switch matix is oversubscribed. >One example I know of is that on a 48 port card every 8 ports share 1Gbit >to/from the backplane. Depending on the traffic by the other 7 this will >create jitter. >(Cisco 450x has 6*1Gbit per slot, 450xE has 8*3G per slot) Ours are Cisco Catalyst 3750 Stack and most of the machines are on the same "brick" of the switch "stack". And still they have very different behaviour as far as ntp is concerned. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
