Hi!
On with the next round of 'bore the list to death' (I hope they
won't kill us both now ...)
Trying to kill the keyboard, [EMAIL PROTECTED] produced:
> > Trying to kill the keyboard, [EMAIL PROTECTED] produced:
> Nope, everything is up to par... I did try not using irqtune... same
> results, so it's not an irq latency problem.
Ok, IRQ works ...
> Because it ends up not being the correct # of blocks :-) try it :-)
I know. :-/
> > The Kernel is not swappable, so what? It does not need to load
> > libraries from HD, it's practically compiled --static (apart
> > from modules). Or am I wrong (again)?
> Yup, it's static... but different libs/compilers produce different code an
> different optimizations for different cpu's...
Yes, but that's true for both a.out and ELF. And since the whole
kernel (minus modules) is kept in memory, it won't fragment in
any way.
> > > Lots of the "EZ-DRIVE" type programs to this...
> > And you get a boot sector virus and can but hope you have
> > a backup. And it's sooo easy to get one.
> No dos, no viruses :-) besides, we have tape backups... (ahem)
Bootsector viruses do not need any OS to work. They just assume
DOS or Windows to get written on the next floppy, too. But the
damage they do is from their own bootstrap code. Insert Diskette
and boot (with A: C: or similar). Instant dead LILO. Note that
most virus infections (before the macroviruses --- which *can*
strike Linux if they find a VB/Excel/whatever they were written
in ...) were bootsector viruses. Even though there were over
2000 virus families(1 to several 100 individual viruses) and
perhaps 100 bootsector viruses.
> > > *ROFL* I won't even comment how old I am or how long I've used linux.
> > Let me guess, you are 18 and use Linux since ... oh, 1985. Aeh,
> > sorry, wrong place, we weren't discussing the jobs managers want
> > to offer or others want to fill. (8 years java experience ...)
> nope... infact I'm a divorced father. :-) surprize...
Not really, I was joking. Which should have been obvious from
the dates. But you *did* date yourself.
> 2: IRQ is a non issue for me (relates to top secret stuff)
Governmental IRQ ... or is that No Such Ir(a)q? *grin*
> I'm litterally glued to it except on weekends, when I tend to my daughter.
You don't sleep? Or do you keep everyone out of the box during
the night?
> > > > > Nope... I have many large multimegabyte databases here.
> > > Actually, most of it is sequentially read. No, I'm not explaining why or
> > > what it is :-)
> > Ok, just one question: How much faster is it read by dd?
> Never timed it. I'm sure it's slower with dd...
I doubt that, unless you read only a part of the database.
> > Oh. Do I have to burn it before reading? Or do you have to
> > kill me before telling me?
> Nope, I just won't tell what it is to save your electrons from burning...
Ouch. e- binding O2 all on their own. That sure is dangerous,
I 'd rather not have that done to me.
[rehashing all info]
> > Well, either I do not spot the right hints now or I happen not
> > to have enough information.
> Ask me and I'll let you know what you need to know... I do believe that I
> have given all info.
Well, you could try bashing at the box until it gives in ... or
offer it more RAM/a faster processor/... if it behaves. :-) For
more we'd need to tune up all relevant debugging levels (kernel,
ftape ...) and maybe hardware to log the transactions between
computer and floppy controller and between it and the tape.
> > Try waving dead chickens over the
> > computer & the tape drives, or sacrifice some blood (yours or
> > others).
> Dead? No. Cut a live one's head off and splash it with the blood...
Or that. But the dead chicken is more commonly used. (Dead,
not frozen, that is.) Or some other rital sacrifice.
> > Wipe it, copy your current root to there (cp -a or tar | tar or something
> (but not dd)). Then the backup root is not fragmented. Boot from it.
> > Test it.
> It isn't fragged now because it was recovered... :-)
> I have to MAKE a fragged fs to test.
Well, I assumed that your TR-1 might or might not work with the
backup. But since you have one, first run from it unfragmented
(just to check) and then fragment it gradually. It should be
interesting to see if any effects turn up.
> > > > *lightbulb*
> > > > Hey, if it was really fragmentation, how do we explain that one
> > > > of them runs OK at 1000 and the other doesn't?
> > > Time sensitive drive?
> > TR-1 should be less sensitive.
> The tape, mebby, the drive? doubtful. tr-1's read fine in the tr-3 deck, at
> the higher speed... so it's gotta be the tape deck... perhaps the IPS of the
> tape is slightly different?
I don't think so, but I don't know either. Just note that I
*did* successfully ran a floppy tape at 2000kbit/s (over an
accellerator, the floppy controller would not work at that rate).
But then ... maybe the TR-1 is aging and dying slowly? And the
TR-3 just needed a bump or so to be realigned? *shrug*
Anyway I think if your old 386 could do it, your P133 should
have more than enough steam to time it better.
> > Damn, you are stubbornly loyal to your users. How much do they
> > pay you?
> More than you could afford. I'll prolly be having ~1000 or more soon too.
> This is why I gotta have something that works, untill I get time to get a
> better backup device... however, if I can help out with this project with
> observations... I can do that :-)
> > How many times do they thank you and make you feel special?
> Every day.
> > How often do they bring you presents and new hardware?
> All the time. I'm serious too! :-)
You are not real. You are an imagination. I actively disbelieve.
Next you say the earth is flat. :-) Or you faked your address
... shouldn't there be an 'heaven.org' or something?
> > Sorry to bust your bubble, but ... problems make me think if
> > they are clearly described (I'm not much of a mind reader). :-)
> Better buy a crystal ball...
But do they work without batteries (or are they included
nowadays)? :-)
> > Who pays you, IDE? :-)
> Shhhh! Quiet! Let's just say I'm improving the interface, and leave it at
> that.
i ..., .. ....'. ... ... ... ... ..... ..... .. .... ide .......
(silent enough? *smirks*)
> > I don't have (usually) unless I have a long uptime. You need to
> > swapout more than 7/8 of the RAM completely(!) to guarantee the
> > continous buffers will be found in a worst case scenario. Yet
> > another reason against floppy tapes and 80x86.
> With 128M, I don't have that happen :-) Mebby you need more memory :-)
No, it's a question of memory fragmentation. It happens when the
4kb swapping pages are big against the amount that is accessed
(perhaps a few 100 bytes). It comes with longer uptime and
long running programs (sendmail, for example) mallocing buffers
dynamically. Just see that you really can load ftape.
> > hits. At 1000 kbit/s (did I write Mbit earlier? *bonk self*)
> > you get 125 Kb/s. With your 16 DMA buffers you have 16*32Kb =
> > 512 Kb buffer (4 seconds). With a 10 MB buffer (no prob for
> > you) you have 'just' 81.9+4 secs reserve. I doubt that swap can
> > take that long.
> Your correct about the timings, I do the buffers like that to prevent the
> shoe-shine crapola that ftape users are all to familiar with.
Never had that problem as a result of too small buffers. Only as
a result of the fast forward/reverse essentially guessing wildly
(and inconsistently between sessions) wrong, causing terrible
overshooting. (BOT->EOT->BOT->EOT ... of fast forward 30 odd
blocks just to spool till EOT(900 blocks away, with one track
just over 1000 blocks in length)).
> The problem is
> not that, infact, it's something unrelated... prolly DMA fights with IDE
> and other anomolies, like IRQ and the software timings, drives with no
> tolerance to timing... It's prolly a combonation of all of it, actually.
Probably. But to test that would need a hardware lab.
> > Humor? Damn, I was trying to mask it as sarcasm. Here goes
> > the planet^W^Wmy image.
> Why does one want an image like that?
Look up BOFH. :-)
Anyway, just joking, only (half) serious.
> > But since you asked: You could wade through the output of
> > ftape (with the debug turned all up, perhaps) and pick out
> > relevant parts.
> Doing so for whatever reasons makes the tape act worse...
Yes, that's documented (see ftape docu) as lots and lots of
data is written on the disk. This degrades tape performance,
but could give us a hint why and how the error occurs.
> > BTW, do you want to know my SSN? *looks expectingly*
> Phone 1-800-U-BYTE-ME and tell them... :-)
Well, I cannot. For one, my phone has no letters, just digits,
so I would have to look up the letters. Then 1-800 won't work
(I doubt they take international calls). Finally, I don't have
a SSN. *grin* No, I am not an illegal immigrant, I just am in
a different continent.
-Wolfgang
--
PGP 2 welcome: Mail me, subject "send PGP-key".
Unsolicited Bulk E-Mails: *You* pay for ads you never wanted.
How to dominate the Internet/WWW/etc? Destroy the protocols! See:
http://www.opensource.org/halloween.html
