Linux-Development-Sys Digest #186, Volume #7 Sun, 12 Sep 99 20:14:00 EDT
Contents:
Underclocking CPU ("Simon Kwan")
Re: Linux real-time clock Y2K support (Richard R Urena)
Re: glibc2.1.2 and libX11 problem (Allin Cottrell)
Re: Linux standards compliance (Kaz Kylheku)
Re: threads (David Schwartz)
Re: threads (David Schwartz)
Re: Linux standards compliance (Nix)
Re: Underclocking CPU (H. Peter Anvin)
Re: You can now use Winmodems in Linux!!!!!!! (M. Buchenrieder)
Re: Writing an own simple bootloader for Linux (H. Peter Anvin)
Re: Underclocking CPU (Jamie Walker)
Re: You can now use Winmodems in Linux!!!!!!! (Nix)
Re: Porting Motif based software... (Nix)
Re: Porting Motif based software... (Juergen Heinzl)
Re: Porting Motif based software... (Paul J Collins)
----------------------------------------------------------------------------
From: "Simon Kwan" <[EMAIL PROTECTED]>
Subject: Underclocking CPU
Date: Mon, 13 Sep 1999 01:18:16 +0800
Hi,
I have two old motherboard that supports 233 and 300 MHz, P, P MMX, AMD,
Cyrix and Winchip. Nowadays, you cannot buy CPU at that low clock rate.
Can a higher speed CPU be used in LOWER clock setting. News was reported
that CPU maker are putting in 'clock lock' to prevent user from clocking
their CPU ABOVE the norminal clock rate. Wonder if the 'lock' prevent
clocking UNDER the norminal rate?
TIA. Appreciate email reply also.
Simon
------------------------------
From: [EMAIL PROTECTED] (Richard R Urena)
Subject: Re: Linux real-time clock Y2K support
Date: 12 Sep 1999 11:23:53 -0400
>> Does anyone know of an application for Linux that will provide protection
>> against real-time clocks that are not Y2K-compliant?
>
>Yes, it's in the kernel. When you boot, if the clock says the year
>is 1950 or less, then the kernel adds 100.
In the kernels I use (2.0.38 and 2.2.7) the cutoff is 1970
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: glibc2.1.2 and libX11 problem
Date: Sun, 12 Sep 1999 12:11:45 -0400
Dawg Lone wrote:
>
> Thanks for the reply, I upgraded from libc5.
> Still I get the _xstat not found when I try to start any windows with it.
What about all your X libraries? For a functional glibc system
they must all be linked against glibc, not libc5. That is, it's
not enough just to replace the "base" libraries when upgrading.
Allin Cottrell.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Linux standards compliance
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Sep 1999 19:10:03 GMT
On 12 Sep 1999 18:32:17 +0100, Nix <$}xinix{[email protected]> wrote:
>I am.
>
>When you pay people to do something, you will attract people whose
>primary interest is in that money. Not the code quality.
>
>And those people will bugger up the code turned out by the rest of us
>(even if just slightly).
>
>Unlinking (even partially) code quality and remuneration *will*
>compromise code quality. (And does.)
By the way, wasn't it you who recently posted to the glibc2 mailing list
pointing out all those glaring bugs in the regex code?
So who buggered that up?
Musta been them *paid* programmers. ;)
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Sun, 12 Sep 1999 12:38:02 -0700
Joseph H Allen wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Schwartz <[EMAIL PROTECTED]> wrote:
>
> > I must admit, it frequently winds up being convenient to do just this,
> >but it really is more elegant to have a 'any thread can do any job'
> >model. This way, you are never forced to have a context switch unless a
> >shared resource is contended for, an I/O operation blocks, or a blocking
> >I/O operation completes.
>
> I've been thinking about this 'any thread can do any job' model some more.
> I think you want a large pool of fixed threads- the limit should really only
> be dictated by how much memory you want to waste on per-thread overhead. I'm
> wondering if all free threads should be waiting on select() though-
> certainly there should be at least as many as there are processors. This
> way a new request will be processed if all of the other threads are blocked,
> and each processor will always be doing something. You may want even more
> threads waiting on select()- perhaps you want some timesharing to take place
> on each processor if you expect each request to take a long time. So should
> there be a semaphore to limit the threads waiting on select() or should all
> threads wait on select()? What happens to threads which are waiting on
> select() when new I/O becomes available- they all must get waken right?
> This is bad right?
Yes, it's bad. You wind up not being able to achieve an absolute
perfection of any thread can do any job, because if all threads were
blocking for network I/O, you'd get too many spurious wakeups. Such is
life.
My usual compromise is to have _one_ thread blocking in select or poll.
All the other threads block on a job queue. This way, the thread
blocking in select or poll can queue all the work that's available and
block back in poll/select. You then have one context switch (assuming
uniprocessor) to a thread in the job queue and that thread can use up
its timeslice doing as much work as possible work (unless it blocks).
> Is there any reason that the threads waiting in select() should have a lower
> priority (at least while they're actually in select()) than blocked threads?
> I'm thinking that you may not want to start new requests if existing threads
> are ready to be scheduled.
It generally happens anyway. If you only have one thread blocking on
poll/select and you have some larger number of 'worker' threads, it
generally isn't necessary. Plus, if you get one CPU intensive request
(on uniprocessor), you'd probably prefer to serve that request a little
bit slower than take on no new requests until that one completes.
As soon as you start messing with priority, you start having to worry
about priority inversion. That and the probable extra cost to the
scheduler make dealing with priority something best avoided unless
you're sure you need it.
> Should threads read and enque requests from all ready fds, or just take the
> first available request? I think it should probably read everything, since
> the context switch overhead from a bunch of read()s in a row is probably
> less than that from a bunch of read()s with delays in between them (the
> cache will be reused if there are delays). On the other hand, there should
> be a limit as to how many requests you accept- so as not to allocate
> infinite memory in the input queue if the clients are feeding you data
> faster than you can process it.
There's a fairly complex architectural question here -- exactly when
should the thread that queues I/O jobs decide to hand off a job? A read
on a non-blocking socket known to be ready for read is not particularly
expensive, so I don't think it's necessarily bad to have a single thread
do all the reading and queue jobs that basically say "process this
data".
The advantage is that your I/O thread gets to run as long as possible,
doing lots of I/O. The disadvantage is that, on SMP, your read
concurrency is limited to one. So some may prefer to simply queue a job
that basically says "this socket is ready to read".
The issue on output is similar. It would take me too long to explain
the rationale here, but I prefer to have the thread that generates the
outbound data do the first non-blocking write if there was no outbound
data 'already waiting' for that socket.
This logic is two-fold. First, your thread blocking in poll/select
can't do anything to a new socket until it finishes its current
poll/select pass, and that could take awhile (it may need to timeout).
Second, the write may complete immediately, saving the overhead of
telling any other thread to do anything or queuing any outbound data at
all.
However, this can cause a 'short packet' phenomenon. The immediate call
to write may not write all the data that might be ready for that socket
at a later point, causing a short packet to be sent. Whether this is an
issue or not depends upon the type of server you are writing. (For a
database, it probably isn't an issue.)
In my opinion, if you expect that the outbound data your 'worker'
thread has ready to send now is the only outbound data you'll be sending
to that connection 'for a while', you're best off to just send it. If
you can't send it all in a non-blocking fashion, then queue the outbound
portion and tell your I/O thread to begin doing the outbound poll/select
thing on that socket to send the rest.
> I'm actually writing a new database, so this discussion is good because I
> have to deal with these issues soon.
It helps to think about these kinds of things very, VERY early.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Sun, 12 Sep 1999 12:40:37 -0700
Leslie Mikesell wrote:
> > This is true but irrelevant.
> >
> > A model of 'one process per connection' that needs to handle ten
> >connections will _always_ need ten context switches. A multithreaded
> >program that does _NOT_ use a model of 'one thread per connection' may
> >be able to handle ten connections without ever switching threads even
> >once.
>
> How do you do that? Aren't you going to do a context switch into
> the kernel and back every time you perform I/O?
There is a tremendous difference between a 'read' call that completes
immediately and a read call that requires putting the current process to
sleep and then scheduling a new one.
> And doesn't
> the kernel know the 'right' process to run when something is
> available for it's connection?
Sure, and therefore it has to do a process context switch each time,
with a pass through the scheduler.
DS
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Linux standards compliance
Date: 12 Sep 1999 18:32:17 +0100
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> I am not suggesting that for pay developers are any worse at writing
> software than volunteers
I am.
When you pay people to do something, you will attract people whose
primary interest is in that money. Not the code quality.
And those people will bugger up the code turned out by the rest of us
(even if just slightly).
Unlinking (even partially) code quality and remuneration *will*
compromise code quality. (And does.)
--
`Don't look at this lest you vomit or spontaneously combust.' --- Documentation
for `zap-last-kbd-macro-event' in XEmacs 21
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Underclocking CPU
Date: 12 Sep 1999 20:41:47 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <7rgn8p$ejf$[EMAIL PROTECTED]>
By author: "Simon Kwan" <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> Hi,
> I have two old motherboard that supports 233 and 300 MHz, P, P MMX, AMD,
> Cyrix and Winchip. Nowadays, you cannot buy CPU at that low clock rate.
> Can a higher speed CPU be used in LOWER clock setting. News was reported
> that CPU maker are putting in 'clock lock' to prevent user from clocking
> their CPU ABOVE the norminal clock rate. Wonder if the 'lock' prevent
> clocking UNDER the norminal rate?
>
Clock locks haven't appeared yet. Most CPUs can be underclocked,
although for most, there is a limit to how low the PLLs can sync.
However, running at 233 MHz or 300 MHz shouldn't be a problem. Of
course, you'd get more bang for your buck getting new motherboards --
they're cheap. :)
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: [EMAIL PROTECTED] (M. Buchenrieder)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Sun, 12 Sep 1999 15:27:21 GMT
"Joon Nan" <[EMAIL PROTECTED]> writes:
>How? Could you please show me. I'm urge to get my modem work.
[...]
Argh. This stupid thread should have died months ago. It is a myth.
Get over it, and buy a real modem.
Michael
--
Michael Buchenrieder * [EMAIL PROTECTED] * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Writing an own simple bootloader for Linux
Date: 12 Sep 1999 20:47:09 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: Lennart Poettering <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> Hello!
>
> I am working on a project to develop an open-sourced MP3-Hardware-Player
> based on a PC-Architecture and Linux. I want to boot from a self-built
> EEPROM-Device on the ISA-Bus. The code on this device shall load a
> Linux-Kernel from another device attached to the parallel Port. For that
> i need to write a very simple, minimalistic bootloader, which gets the
> address of a memory-block containing the raw linux-kernel.
>
> How is this done? Has anybody already written such a simplistic
> bootloader?
> What do i need to start a linux-kernel? Where do I get information about
> it?
>
> I just wanted to be sure that I do not reenvent the wheel by looking on
> the sourcecodes of LILO and loadlin.
>
This is true for an i386 platform which uses a BIOS *only*: (For a
non-BIOS application, you need to replace the setup with your own
code, at the very least.)
The basic idea is that the kernel is composed of some set of 512-byte
sectors. The kernel is divided into three regions: bootsect, setup,
and kernel. bootsect is always one sector (512 bytes). It contains
the size of the setup. The setup contains a header, which you will
need to touch to support bzImage or initrd. Look at
linux/arch/i386/boot/setup.S.
For a zImage kernel, the bootsect+setup are loaded at absolute address
90000h, then the kernel is loaded at 10000h.
For a bzImage kernel, the bootsect+setup are loaded at absolute
address 90000h, then the kernel is loaded at 100000h.
For either, you jump to 9020:0000h to start the kernel.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: Jamie Walker <[EMAIL PROTECTED]>
Subject: Re: Underclocking CPU
Date: Sun, 12 Sep 1999 20:55:28 +0100
In article <7rgn8p$ejf$[EMAIL PROTECTED]>, Simon Kwan
<[EMAIL PROTECTED]> writes
>Hi,
> I have two old motherboard that supports 233 and 300 MHz, P, P MMX, AMD,
>Cyrix and Winchip. Nowadays, you cannot buy CPU at that low clock rate.
> Can a higher speed CPU be used in LOWER clock setting. News was reported
>that CPU maker are putting in 'clock lock' to prevent user from clocking
>their CPU ABOVE the norminal clock rate. Wonder if the 'lock' prevent
>clocking UNDER the norminal rate?
Probably, you can't run a new CPU in an old M/B. Although, you *might*
be able to.
Most new chips use a different socket/slot on the board and different
methods of communicating with the rest of the computer (different
chipsets), and/or different voltages.
You *might* be able to get an AMD K6(-2/3) to work at a reduced speed on
an old board, but boards are so cheap now, it's not really worth it. The
'clock lock' you speak of is really a multiplier lock - CPU's run at
several times faster than the speed at which the various 'buses' of your
computer run (communication path between RAM, PCI cards etc), and use a
clock multiplier to get to the required speed. For example, my Celeron
300a has a multiplier of 4.5 and runs on a 66Mhz bus (4.5*66 = ~300).
The *multiplier* is locked on almost all recent Intel chips, but Intel
have no current methods of preventing me from running the bus on my chip
(and all other CPUs they produce) at 100Mhz, to give 4.5*100, or 450Mhz.
AMD chips do not have this restriction BTW, but are not as reliable to
overclock. I have seen an AMD 300 running underclocked because the CPU
heatsink/fan was not big enough, but this was on a board that supported
the correct voltages.
HTH, but if you didn't already know at least some of that, then you
would probably find it difficult to achieve what you want and risk
damaging CPUs by getting voltages wrong etc, and so I'd say - buy a new
M/B (most will autodetect voltages etc in software)!
(FYI this is very off-topic in this Linux newsgroup)
--
Jamie Walker, http://www.howgarth.demon.co.uk/
LaL Computers: http://lal.rvx.net/ <- for cheap computer hardware.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: 12 Sep 1999 23:31:30 +0100
webx1 <[EMAIL PROTECTED]> writes:
> shoot me that program please, I would to go on the net with my winmodem!!!
>
> thanks a lot!!
>
> ------------------ Posted via CNET Linux Help ------------------
> http://www.searchlinux.com
More proof, as if we needed it, that the parents of those who thought of
`CNET Linux Help' should have been sterilised at birth.
--
`Don't look at this lest you vomit or spontaneously combust.' --- Documentation
for `zap-last-kbd-macro-event' in XEmacs 21
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Porting Motif based software...
Date: 12 Sep 1999 23:27:20 +0100
[EMAIL PROTECTED] (Juergen Heinzl) writes:
> >Are there any free Motif implementations out there?
>
> Metrolink Motif, $149 for the 2.x version and it comes
> with the XRT widget set.
? This must be some new meaning of the word `free' with which I am
unfamiliar ;)
(Or is it expensive but libre stuff? I didn't think it was, but I may be
wrong...)
--
`Don't look at this lest you vomit or spontaneously combust.' --- Documentation
for `zap-last-kbd-macro-event' in XEmacs 21
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Porting Motif based software...
Date: Sun, 12 Sep 1999 23:26:31 GMT
In article <[EMAIL PROTECTED]>, Nix wrote:
>[EMAIL PROTECTED] (Juergen Heinzl) writes:
>
>> >Are there any free Motif implementations out there?
>>
>> Metrolink Motif, $149 for the 2.x version and it comes
>> with the XRT widget set.
>
>? This must be some new meaning of the word `free' with which I am
>unfamiliar ;)
>
>(Or is it expensive but libre stuff? I didn't think it was, but I may be
>wrong...)
My reference regarding Metrolink was not an answer to the "free"
but the Motif part as yes, lesstiff is free while Metrolink is
not. Now Metrolink is 2.x and lesstiff is not. Well, either I've
been quoted wrong or did not read the posting thoroughly enough,
nothing unusual as I love to keep late hours %*).
Shall the power be with your machine,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Paul J Collins <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Porting Motif based software...
Date: 13 Sep 1999 00:26:12 +0100
>>>>> "Nix" == Nix <$}xinix{[email protected]> writes:
Nix> [EMAIL PROTECTED] (Juergen Heinzl) writes:
>> >Are there any free Motif implementations out there?
>>
>> Metrolink Motif, $149 for the 2.x version and it comes with the
>> XRT widget set.
Nix> ? This must be some new meaning of the word `free' with which
Nix> I am unfamiliar ;)
Nix> (Or is it expensive but libre stuff? I didn't think it was,
Nix> but I may be wrong...)
Nope, it's not free at all, in any sense of the word. You can
distribute staically and dynamically linked apps, but not the libs
themselves. It might be worth checking out LessTif (www.lesstif.org)
and see if it is good enough. Mgv and snd work fine with it and they
are close to getting Communicator working without a rebuild, i.e.,
full binary compatibility.
Paul.
--
Paul Collins <[EMAIL PROTECTED]> Public Key On Keyserver.
Fingerprint: 88BA 2393 8E3C CECF E43A 44B4 0766 DD71 04E5 962C
"I am a stranger in a strange land,
distracted by bright and shiny objects."
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
