Re: Different speed CPUs show up as same speed

>
> I only see problems where there are problems; we're not talking about
> hypothetical computers, we're talking about actual computers where we can
> actually run code. I know that my kernels and none of my binaries are
> compiled with SSE. I also know that most distributed binaries certainly
> never use such code.

Well but what is with others? Having the possibility to use Intel's C Compiler 
enables one to use SSE without changing a bit of code, the speed improvement 
is very high (on my box it was factor 2 compared to gcc 2.95.3 with povray). 
So there is a point - just more logic has to be implemented in the kernel, 
for just a bunch of people - do we want to be an operating system designed 
only for a friction of computer users?

>
> > No, it isn't supported. "Works for you" and "supported" are
> > different. "Supported" doesn't mean "will boot and run". "Supported"
> > means that the bulk of us working on NetBSD will care enough to help
> > if it doesn't work or stops working. "Supported" also means "we
> > recommend/encourage this usage".
>
> Fine. So it's known to work, but not supported as in "Officially Approved
> By The Entirety Of NetBSD". I don't see the point of making a big deal
> about it. As I said before, it's not like we're making guarantees here or
> anything.
>
> > We don't encourage this bad idea. We say outright it is a bad idea. It
> > isn't supported. If it "happens to work for you", well fine, but we
> > aren't going to go out of our way to make sure it will work, or to
> > make sure it continues to work.
>
> Please illustrate how, aside from speculation, it's a bad idea.  Will you
> also tell the people running SPARCs that what they're doing is bad? This
> attitude is not a good one. Code should be correct no matter what.
>
> An example where assumptions would be bad: what if a CPU in a dual
> processor system started overheating, and was automatically throttled
> down? Would we want our kernel to panic because one CPU is now a different
> speed than the other? I prefer correct code.

I don't think this is a good example, because the CPUs are assumed to run on 
full speed under normal circumstances. If one cpu get's down, the best 
solution would only be to shut down this box to exchange broken hardware or 
to set up better cooling. If the box built up correctly this should only 
happen with broken fans, which most mp boards signal with loud beeping, so 
why not changing fan before the cpu overheats (most intel cpus in my 
experience run for some time, before overheating if a heatsink is attached). 
And I don't think the kernel will panic, as far as I understand these 
calibrations loops, they are for scheduling and stuff, when an exact number 
of seconds or so has to be hit, so some process just doesn't get it's time or 
is woke up too late, the system will run, but slow, doesn't it?

>
> > If, for example, you said "hey, the change you just made broke my
> > differing-CPU MP configuration", I doubt anyone would care enough to
> > spend time debugging it for you, which is very different from what
> > would happen if you noted that a supported configuration was
> > broken. If you then provided a patch that made it work for you again
> > and it caused no harm to anyone else, it might be accepted -- but it
> > is unlikely anyone else would bother to create such a patch.
> >
> > That's what "not supported" means.
> >
> > So, to be clear, consensus seems to be "different CPUs running in MP
> > is not supported". Not "will never happen to run". "Not supported".
>
> When you make the distinction that way, fine; again, I care little about
> semantics. So it's not "supported", but it certainly does run, and there
> are no technical reasons it shouldn't.
>
> I will do my best to test these machines with NetBSD as much as I can, and
> I will even look at the CPU spinup code to see if I can correct the mostly
> aesthetic speed reporting bug. And if something should "break" so that
> these systems no longer work, I will do my best to figure out what caused
> the break and suggest alternative, or possibly "more correct", ways of
> doing that thing.
>
> Thanks,
> John Klos
> Sixgirls Computing Labs

-- 
Greetings
Matthias Kretschmer