On 05/30/2013 03:09 AM, Holm Tiffe wrote: The biggest thing with that kind of speedup is first its a trivial amount and the other is if you go too far system reliability will be poor and show up as unexpected crashes with known solid software (data errors). That said I've pushed the clock on 11/23 board once too see and the 13mhz clock was wound up to 25mhz using a external source. I started seeing errors above 18mhz but they were random, seems bus timing and memory timing all had to be happy and I was pushing the margins. I eventually put in a clock module for 15.8mhz as I had one. For that it was a modest speed up as the 11/23 is slower to start with. Generally overclocking is problematic because the system timing is based on it and there may be items other than the CPU that have lower limits. Allison

On Thu, 30 May 2013, Dave McGuire wrote: This became extremely interesting when I read this quickly and saw "GHz" instead of "MHz" ;) -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

Dave McGuire wrote: Nah. Just cool it with superfluid helium. Peace... Sridhar

-- Cory Smelosky Sent from a mobile device On 30 May 2013, at 12:31, "Dave McGuire" <mcguire at neurotica.com> wrote: Yup. ;) It'd be pretty unstable, too. I've heard fire affects the reliability of silicon. ;)

On 05/30/2013 12:26 PM, Cory Smelosky wrote: At 25 a lot of things were funky and not running well, UODT was about it. Oddly heat wasn't the issue. Clearly propagation delays were. I had to look to see I didn't mistype mhz! ;) At that time generating a signal above 512mhz was outside my equipment capability. Over the years I've pushed silicon many times and often heat was not the issue, as it would quit working usually long be fore that became an issue. Though I did take a 6mhz z80 to 10mhz and it would run there only if kept cooler than 100F, any warmer and it would quit and Z80s (nmos) run warm to start so it was glued to a Peltier cooler to get down to about 50f. It wasn't overheating it was a matter of propagation times shifting enough with temperature to not make it anymore. FYI it only worked because I had memory that was faster than 35ns, the bus and control signal timing had far worse timing margins than the actual 10mhz part. Cmos parts like the 1802 can be pushed too, and since they run stone cold in their normal speeds it's more timing issues that get in the way. I ran the same test on a PDP-8e once and found with fast semiconductor (not commercial) memory it was far faster and could hit 2x, almost, at that point all the IO cards and the bus started to get really unhappy and stop talking. Most of the time internal clock and other timing distribution or bus switching is more likely to stop the show before junction heating. Its only the higher density parts that are already warm for that reaaon and can switch that fast but getting rid of the heat is their problem. Then again you need to assure the rest of the hardware can keep up as often that is more of a limiting factor. Allison

On May 30, 2013, at 11:41 AM, Dave McGuire <mcguire at neurotica.com> wrote: Yeah, the thing with at least the 11/23 is that most of the board runs on a common base clock, including the QBUS logic. There's no separate clock domain for that. So if you're ramping up the speed of the CPU, you're also cutting down on your timing for QBUS, and the 11/23, slow as it is, is timed pretty close to the QBUS minimums already. There's not a lot of room before you start violating setup/hold timings for the other boards in the system (which is essentially what Allison said). - Dave