Re: Testers please!
In message <[EMAIL PROTECTED]>, Jim Bryant writes: >since there is only a single master clock oscillator, there really >should be no frequency difference between CPUs. As long it runs constantly: yes. As soon as you have clock-stop events you will have different resync times for the on-chip PLLs. >Ideally, motherboards should be >designed to have equal length clock lines to each CPU, They are, but that doesn't mean that the PLL'ed core frequencies are in lockstep when the clocks change. >the current price of accurate TCXOs is low enough to be economical in >PCs, and these seriously reduce the drift compared to the cheezy TTL >clocks currently used. There are no cheesy TTL clocks used. There are random encapsulated rock with pretty high-quality drive circuitry and PLL generation of all sorts of other frequencies. >speaking of atomic breakdown... they could start making cheaper >cesium-beam tubes given the current level of the nuclear waste issue The actual amount of Cs in the Cesium unit has no cost impact. There are man components of a Cs unit which carry significantly higher pricetags than the few grammes of Cs. A un-optimally constructed Cs is worse than a low-cost Rb unit. >Cesium beam tubes are essentially extremely accurate >narrow bandwidth filters, and not oscillators. It is neither. >with russia having made two seperate threats of aggression to destroy >the entire planet with nuclear weapons in the past twelve months [...] Lets not get too far from the topic, OK ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
... > > One question comes to mind: is there a way that the TSCs could become > > desynchronized somehow? Even though all CPUs run at the same frequency, > > isn't there a strong possibility for slight frequency deviation since > > we use crystal oscillation instead of a more accurate atomic breakdown > > for regulation, or am I just smoking crack? > > time for rehab, dude. > > since there is only a single master clock oscillator, there really > should be no frequency difference between CPUs. There is the a phase > difference caused by differences in conductor lengths between the > master clock and the CPUs, but this difference is fixed by the length > of the conductor and the laws of physics. Granted, all crystals have > drift over time and temperature, but this drift should be identical > for all CPUs on the same clock bus. Ideally, motherboards should be > designed to have equal length clock lines to each CPU, thus > eliminating this phase difference, especially with multiple selectable > clock speeds which would change the wavelength, and thus the phase > difference if the lines are of differing lengths. And I would suspect if some one was to go look at the layout requirements in Intel's design data for SMP boards you would find it is a requirement that all CPU's in an SMP system have a very minimal phase skew in the clock driven to the chip. How else are you going to run in sync with the shared processor bus. I suspect that the allowed margin on the phase of the clock pin is specified in pico seconds, and probably near 50 or so, given the 100Mhz nature of this signal. 73 to KC5VDJ, KD7CAX -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
In reply: > On Tue, 21 Sep 1999, Luoqi Chen wrote: > > > This reminds me about the usage of TSC counter on SMP. First even though > > we don't use TSC for time keeping on SMP, the TSC frequency from calibration > > is still valid (at least for BSP), and we can show it in the cpu identification > > message. Second, the listed reason for not using TSC on SMP is the inability > > to synchronize TSCs on all cpus. My question is, is it really necessary? > > TSC is initialized to 0 at hardware reset, which should happen to all CPUs > > at the same time (invalid assumption?), in another words, all TSCs should be > > automatically synchronized. > > ISTRT something I did long ago was kill the TSC reset FreeBSD did, so > there should be no reason that they won't be all at the same place. I > am willing to bet half my farm that the biggest problem was that we > did that, and barring that we could have always done SMP using the TSC. > > One question comes to mind: is there a way that the TSCs could become > desynchronized somehow? Even though all CPUs run at the same frequency, > isn't there a strong possibility for slight frequency deviation since > we use crystal oscillation instead of a more accurate atomic breakdown > for regulation, or am I just smoking crack? time for rehab, dude. since there is only a single master clock oscillator, there really should be no frequency difference between CPUs. There is the a phase difference caused by differences in conductor lengths between the master clock and the CPUs, but this difference is fixed by the length of the conductor and the laws of physics. Granted, all crystals have drift over time and temperature, but this drift should be identical for all CPUs on the same clock bus. Ideally, motherboards should be designed to have equal length clock lines to each CPU, thus eliminating this phase difference, especially with multiple selectable clock speeds which would change the wavelength, and thus the phase difference if the lines are of differing lengths. the current price of accurate TCXOs is low enough to be economical in PCs, and these seriously reduce the drift compared to the cheezy TTL clocks currently used. speaking of atomic breakdown... they could start making cheaper cesium-beam tubes given the current level of the nuclear waste issue if they felt like it, provided some kind of untamperable enclosure can be built [30 year half life, biologically behaves like potassium and goes straight for the muscle, 200 day biological half-time]. let's not bury nuclear waste, let's put it to use IN PCs! even then, such a clock would only act as a reference filter to correct a running oscillator. Cesium beam tubes are essentially extremely accurate narrow bandwidth filters, and not oscillators. with russia having made two seperate threats of aggression to destroy the entire planet with nuclear weapons in the past twelve months [MAD is still a policy, they launch, everybody launches], GPS/GOES is not a good idea for clock synchronization. an EMP pulse would take the sats out, but then many computers would be zapped at the same time anyhow, thus making this a moot point for anything that is plugged in at the time or has cables attached at the time. [this is not intended to be a political statement, nor am i bashing common russians, this is just a reality check]. jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
In message <[EMAIL PROTECTED]>, Luoqi Chen writes: >> people have found sufficiently many cases where the counters are >> not in sync after the BIOS is done. >> >I would really like to know how they managed to read the TSCs simultaneously, >or they resorted to some kind of statistical means (which I tried without >much success, maybe I will try later with some kernel hooks). The differences were pretty significant in offset, I havn't heard any numbers from them on skew, and I don't know of anybody who have tried to measure it. The trouble with N counters for N>1 is that you need to add code to synchronize AND syntonize them, you need code to make sure time is monotonic no matter what and yada yada yada. By the time you're done the i8254 doesn't look so bad after all... The ACPI counter is a good sized step in the right direction, they should have made it PCI clock driven, to get better resolution but I suspect the fact that they didn't is a sign that the PCI clock will be power munged at some point. For "general purpose" time a clock which is about the resolution of the IO busses is sufficient, the ACPI is a little low on frequency, but hey, it's miles better than the i8254, and the APM/ACPI will not fuck with it's frequency. For high resolution timing of "in-cpu" events, the TSC is still the way to go, and nothing (except SMP complexity) prevents it from being used for that, and it is probably pointless to convert the data to nanoseconds until the difference has been found in the end anyway. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
> >TSC is initialized to 0 at hardware reset, which should happen to all CPUs > >at the same time (invalid assumption?), in another words, all TSCs should be > >automatically synchronized. > > They are not. The PLL is local to each cpu and every single > clock-stop/start event has then inching away from each other because > the on-chip VCO is very temperature dependent. Furthermore Linux The internal clock is phase-locked to an external clock source, which should be the same bus clock and identical for all cpus. The multipliers for the internal clocks should also be identical (in almost all cases unless you design your own mother board). The highest multiplier as of today is 6x (600MHz cpu on a 100MHz bus), it might increase over time, but I expect it to be still around 10. If the PLL's accuracy is 1%, the difference between two cpus could at most be 10% (or 3% = 1% * sqrt(10), assuming a Gaussian distribution of the drift) of the internal clock cycle, that is 10% (3%) of the time you might get two different readings (differ by 1) if you read TSCs of two cpus simultaneously, that's still much more accurate than the i8254 timer. > people have found sufficiently many cases where the counters are > not in sync after the BIOS is done. > I would really like to know how they managed to read the TSCs simultaneously, or they resorted to some kind of statistical means (which I tried without much success, maybe I will try later with some kernel hooks). The multiplier is set at hard reset, so BIOS couldn't change that (some mother boards may be soft configurable, but the change has to take effect after next reset). Bus clock is external, BIOS couldn't change that either. So the internal clock is not affected by BIOS. Now it would be really hard or me to believe that TSC is not a simple counter that increments at each internal clock edge. I am very skeptical about the Linux people's findings. > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
In message <[EMAIL PROTECTED]>, Luoqi Chen writes: >Second, the listed reason for not using TSC on SMP is the inability >to synchronize TSCs on all cpus. My question is, is it really necessary? Strictly speaking no, it isn't necessary, but unless they are in sync the timekeeping code gets very complex. See Dave "ntp" Mills code to hold them in sync. >TSC is initialized to 0 at hardware reset, which should happen to all CPUs >at the same time (invalid assumption?), in another words, all TSCs should be >automatically synchronized. They are not. The PLL is local to each cpu and every single clock-stop/start event has then inching away from each other because the on-chip VCO is very temperature dependent. Furthermore Linux people have found sufficiently many cases where the counters are not in sync after the BIOS is done. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
> One question comes to mind: is there a way that the TSCs could become > desynchronized somehow? Even though all CPUs run at the same frequency, > isn't there a strong possibility for slight frequency deviation since > we use crystal oscillation instead of a more accurate atomic breakdown > for regulation, or am I just smoking crack? They should all be using the same clock source, so that's not an issue. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
On Tue, 21 Sep 1999, Luoqi Chen wrote: > This reminds me about the usage of TSC counter on SMP. First even though > we don't use TSC for time keeping on SMP, the TSC frequency from calibration > is still valid (at least for BSP), and we can show it in the cpu identification > message. Second, the listed reason for not using TSC on SMP is the inability > to synchronize TSCs on all cpus. My question is, is it really necessary? > TSC is initialized to 0 at hardware reset, which should happen to all CPUs > at the same time (invalid assumption?), in another words, all TSCs should be > automatically synchronized. ISTRT something I did long ago was kill the TSC reset FreeBSD did, so there should be no reason that they won't be all at the same place. I am willing to bet half my farm that the biggest problem was that we did that, and barring that we could have always done SMP using the TSC. One question comes to mind: is there a way that the TSCs could become desynchronized somehow? Even though all CPUs run at the same frequency, isn't there a strong possibility for slight frequency deviation since we use crystal oscillation instead of a more accurate atomic breakdown for regulation, or am I just smoking crack? > > -lq > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
> If you have a PIIX4 based SMP system and run current, could you > please try out this patch: > > http://phk.freebsd.dk/piix/ > > I'm very interested in hearing if there are any measurable difference > apart from clock granularity being 3 times better. > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > This reminds me about the usage of TSC counter on SMP. First even though we don't use TSC for time keeping on SMP, the TSC frequency from calibration is still valid (at least for BSP), and we can show it in the cpu identification message. Second, the listed reason for not using TSC on SMP is the inability to synchronize TSCs on all cpus. My question is, is it really necessary? TSC is initialized to 0 at hardware reset, which should happen to all CPUs at the same time (invalid assumption?), in another words, all TSCs should be automatically synchronized. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
In reply: > If you have a PIIX4 based SMP system and run current, could you > please try out this patch: > > http://phk.freebsd.dk/piix/ > > I'm very interested in hearing if there are any measurable difference > apart from clock granularity being 3 times better. just cvsupped, added your changes, and am building world and a new kernel. i'll get back to ya. jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
In message <[EMAIL PROTECTED]>, Peter Wemm writes : >Poul-Henning Kamp wrote: >> >> Ok, noted. I changed to to fail the probe but still use the hardware. > >If intpm is probed first (the smbus driver), your probe won't even get >called. I think we need an early quirks or hooks handler in the pci probes >to handle stuff like this. For example, we have hooks fixing up a handful >of wierd bios misconfigurations, collecting these together via a quirks >table or whatever would also give a convenient place for you to hook this >sort of thing into, and without it being dependent on link or probe order. sigh... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
Poul-Henning Kamp wrote: > > Ok, noted. I changed to to fail the probe but still use the hardware. If intpm is probed first (the smbus driver), your probe won't even get called. I think we need an early quirks or hooks handler in the pci probes to handle stuff like this. For example, we have hooks fixing up a handful of wierd bios misconfigurations, collecting these together via a quirks table or whatever would also give a convenient place for you to hook this sort of thing into, and without it being dependent on link or probe order. > Poul-Henning > > In message <[EMAIL PROTECTED]>, Peter Wemm writ es > : > >Poul-Henning Kamp wrote: > >> > >> If you have a PIIX4 based SMP system and run current, could you > >> please try out this patch: > >> > >>http://phk.freebsd.dk/piix/ > >> > >> I'm very interested in hearing if there are any measurable difference > >> apart from clock granularity being 3 times better. > > > >There is a problem with it as it tries to claim the same device as claimed > >by pcisupport.c and intpm.c.. pcisupport.c is where some folks have been > >hanging Tor Egge's RTC SMI trap patch from.. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
Ok, noted. I changed to to fail the probe but still use the hardware. Poul-Henning In message <[EMAIL PROTECTED]>, Peter Wemm writes : >Poul-Henning Kamp wrote: >> >> If you have a PIIX4 based SMP system and run current, could you >> please try out this patch: >> >> http://phk.freebsd.dk/piix/ >> >> I'm very interested in hearing if there are any measurable difference >> apart from clock granularity being 3 times better. > >There is a problem with it as it tries to claim the same device as claimed >by pcisupport.c and intpm.c.. pcisupport.c is where some folks have been >hanging Tor Egge's RTC SMI trap patch from.. > >Cheers, >-Peter >-- >Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
Poul-Henning Kamp wrote: > > If you have a PIIX4 based SMP system and run current, could you > please try out this patch: > > http://phk.freebsd.dk/piix/ > > I'm very interested in hearing if there are any measurable difference > apart from clock granularity being 3 times better. There is a problem with it as it tries to claim the same device as claimed by pcisupport.c and intpm.c.. pcisupport.c is where some folks have been hanging Tor Egge's RTC SMI trap patch from.. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
In message <[EMAIL PROTECTED]>, Dav id Scheidt writes: >On Sun, 19 Sep 1999, Poul-Henning Kamp wrote: > >> >> If you have a PIIX4 based SMP system and run current, could you >> please try out this patch: >> >> http://phk.freebsd.dk/piix/ >> >> I'm very interested in hearing if there are any measurable difference >> apart from clock granularity being 3 times better. > >What sort of tests would you like done before and after? Any test you can think of really. I don't expect any problems, but I am very interested in the performance difference if any, since that would give me a good indication if it is a worthwhile job to spend more time on obfuscat^H^H^H^H^H^H^Hptimizing the timecounter code. As far as I can tell, access to the PIIX timecounter is about 2.5 microseconds faster than to the i8254. In relative terms it is about a factor 3 faster. You can flip forth and back between the old and new behaviour with: New: sysctl -w kern.timecounter.hardware=PIIX (if it refuses you probably don't have the PIIX4 hardware) Old: sysctl -w kern.timecounter.hardware=i8254 -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
On Sun, 19 Sep 1999, Poul-Henning Kamp wrote: > > If you have a PIIX4 based SMP system and run current, could you > please try out this patch: > > http://phk.freebsd.dk/piix/ > > I'm very interested in hearing if there are any measurable difference > apart from clock granularity being 3 times better. What sort of tests would you like done before and after? David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Testers please!
If you have a PIIX4 based SMP system and run current, could you please try out this patch: http://phk.freebsd.dk/piix/ I'm very interested in hearing if there are any measurable difference apart from clock granularity being 3 times better. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
