2 pane, swiss army knife file manager?

[Gene Heskett]

On Tuesday 27 November 2012 09:32:22 Basil Chupin did opine:

> On 21/11/12 03:59, Gene Heskett wrote:
> > On Tuesday 20 November 2012 11:42:11 Basil Chupin did opine:
> >> On 20/11/12 17:41, Ric Moore wrote:
> >>> On 11/20/2012 12:00 AM, Basil Chupin wrote:
> >>>> On 20/11/12 11:49, Gene Heskett wrote:
> >>>>> On Monday 19 November 2012 19:47:16 Basil Chupin did opine:
> >>>>>> On 20/11/12 05:54, Gene Heskett wrote:
> >> [...............
> >> 
> >>>>> Not a thing Basil.  But if I click on a graphics file, it will
> >>>>> show it to
> >>>>> me, but its own screen will be destroyed in the process,
> >>>>> unrecoverable ANAICT.
> >>>>> 
> >>>>> Cheers, Gene
> >>>> 
> >>>> As I said, something wrong at your end :-) . I can view any graphic
> >>>> I want without losing mc when I close the graphic.
> >>>> 
> >>>> Next.........:-)
> >>> 
> >>> Gene is using the nouveau <sp?> driver which has a ways to go. I
> >>> think he wouldn't get that tearing if he managed to install the
> >>> nvidia driver with hockey. But, his custom kernel seems to mung
> >>> that up. Ric
> >> 
> >> That would explain it - the use of nouveau driver.
> >> 
> >> But if he compiled his own kernel correctly then he should be able to
> >> compile the nVidia driver for it. I compile my own nVidia driver
> >> every time, each time a new version is released (or even a beta, as
> >> in the latest one 310.14).
> >> 
> >> BC
> > 
> > Possibly Basil, but the OEM nvidia drivers absolutely demolish the
> > latency figures of the real time kernel, making it impossible and
> > unsafe to run machinery with that driver.  I have tried, and I have a
> > container I toss broken $20 carbide tools into that has about a two
> > hundred bucks worth of tools the nvidia driver broke by stalling a
> > motor with its 200 millisecond long IRQ lockouts.
> 
> To begin, I hadn't responded earlier because I was looking for some
> doco, which I still failed to find, and also doing some magical things
> with Cinelerra and well as installing an upgrade on my wife's computer.
> 
> Re the above, you mention 3 things which I found interesting and for
> which it would be nice to have some information.
> 
> The first is your mention of "the OEM nvidia drivers". Do you mean the
> basic, nouveau driver which is used when you install the the distro you
> are using?
> 
OEM, meaning the binary only blob you can download from nvidia.

> Secondly, you mention "the real time kernel". Do you actually mean a
> 'real time kernel' or do you mean something else? I am not aware that
> there may be a real time kernel as I understand that such a beast is
> difficult to put together and hard to keep updated because of all the
> patches. But I have to say that I know nothing about this subject.

The RTAI patched kernel is that. We measure its latency as the amount of 
time the IRQ is issued until the IRQ is serviced.  Motherboards vary widely 
and ATM the best of the lot is the intel atom D525MW board.  This 1.6Ghz 
dual core processor, with hyper-threading turned off in the bios, and 
booted with the isolcpus=1 argument added to the grub kernel line, service 
an interrupt in 2.x microseconds.  Even when its busy running 2 or 3 copies 
of glxgears and browsing the web, it might log 7 microseconds while the 
firefox window itself is being initially drawn.

I have two of them, with this interrupt frequency set for a 23 microsecond 
interval.

The reason for this is that when you are issuing step and dir signals to a 
stepper motor, rotor inertia in the motor will cause its performance to be 
destroyed, if when its turning 200+ rpms, something interferes with that 
nice steady issuance of those steps.  The motor might skip fwd from its 
rotor inertia, but will stop.  That is what steppers do.  But when that 
disturbance stops, and this heartbeat resumes, the computer, which has NO 
feedback from the motor telling it the motor stopped, resumes issuing those 
step pulses at a rate commensurate with 200+ rpms, the motor isn't capable 
of resuming that speed from a dead stop, probably with the rotor ringing 
back and forth half a step, trapped in the stopped magnetic field somewhat 
less than a full step from that sudden stop, and resuming that speed in 
slightly over 1 degree of shaft rotation.  It physically cannot be done, it 
must be re-accelerated to that speed.  We typically issue these steps at a 
multiple rate because the drivers are smart, controlling the currents in 
the individual coils so that rather than turning a full 1.8 degrees per 
incoming step signal, the currents are adjusted so that it only turns 1.8/4 
or 8, maybe even 16.  In that way, the motors can turn pretty smoothly even 
at creep speeds.

That should explain both the requirement, and the reason we can't use the 
nvidia blob, ever.  The nvidia blob gets some of its speed by hogging and 
locking out competing IRQ's, a fact that we have personally clocked at
something in excess of 200 milliseconds!  On this machine, using the 
nouveau driver, running that 'base loop' at 25 microseconds, there will be 
at least an 18 microsecond uncertainty to this timing.  That is not 
tolerable but this machine is not actually turning motors either. By 
slowing this base loop, and the motors maximum speeds a bit, to 50 
microseconds, that 18 microsecond uncertainty would not be so dangerous to 
the part being cut out, but since there is an ideal cut chip size for best 
tool life, you may as well slow the spindle motor too in order to be 
cutting a big enough chip to carry the tool dulling heat away.

I have short tool life on my small machines because neither of them has the 
spindle horsepower to actually cut at the ideal speed.  But that is the 
machines fault, not Linux's.

> Thirdly, your very specific reference that your motor is being stalled
> by "200 millisecond long IRQ lockouts". I couldn't help smiling when I
> read that and thought to myself, "Why not 201 or 202.3 milliseconds?"

Because it was a SWAG in the first place, we cannot measure this while 
running the machines, so we have a 'latency-test' routine that we can 
start, leave running, and go do the other things these boxes do.  It 
records this "maximum jitter" So I just restarted it, stopped firefox, 
restarted it, and then started "dtvsnr 24" which burns cpu because it is 
decoding the most distant tv signal I get in order to actually measure its 
signal to noise ratio, which is about 16 db, not perfect, but usually 
watchable. However, while I am typing at about 1/2 my usual speed, the 
screen updates are about 1 character every 2 or 3 seconds, so this machine, 
a 4 core phenom, is figuratively busier than a one armed paper hanger.

Under these conditions the 1 millisecond servo thread has an uncertainty to 
its timing of about 28 microseconds, which is good.

The base thread that normally would be issuing the step signals out the 
parport, is as late as 27 microseconds, which explains the sluggishness I 
as the user am seeing.  The machine is almost unusable. I've stopped those 
2 apps now, but it appears HTOP needs some TLC, it is not reporting load 
averages.  Even after I restarted it.

> :-) . How do you manage to measure this value?

As above.
> :
> > That is reason #1.
> > 
> > Reason #2, is that I have yet to build a custom kernel that the nvidia
> > driver would allow itself to be installed to.  The failure message,
> > 100% of the time is that it is already installed.
> 
> If you read the instructions given on the nVidia site you will find that
> there is cli which you can use to uninstall an existing nvidia driver.
> But when I compile mine I am 'told' that there a driver already
> installed and do I want it removed - to which, of course, I answer with
> a "Y".

Which has yet to work on any box I've tried it on.
 
> The other thing I wanted to mention, and it was re this that I was
> searching for some dox I have/?had, about rolling your own kernel.
> 
> Some years ago I used to roll my own kernel because the kernel came in 3
> flavours: a pae one, a standard one, and some other. (This by the way
> has nothing to do with Ubuntu as it wasn't a gleam in dadda's eyes at
> that time :-) .) The point of me mentioning this is that as far as I can
> remember both the pae and the standard kernels were meant to be used on
> _servers_ and therefore had a high latency (don't ask where, I said I
> know nuffin' I just followed instructions :-) ); they were not really
> designed for use on fast desktops - which is the reason why I used to
> roll my own and fiddled with some parameters which gave better results
> on a desktop. I wish I could find the dox I was using which spelt out
> the parameters which needed to be altered :-( , but one of then was to
> increase somethings latency from the default of 1000 Hz to ?????.

pae is the default for an rtai enabled build.  FWIW, any sms stuff in the 
bios must also be disabled.
 
> >    So I startx, and either fail
> > 
> > outright, or wind up with an /etc/X11/xorg.conf that has been
> > destroyed because it got overwritten by a vesa config.  So you spend
> > 3 hours screwing around trying to recover a working X server, and in
> > the end wind up doing a full re-install after saving as much of your
> > work as you can to someplace it won't get nuked by the install.
> > 
> > When the nvidia driver decides to play nice with the IRQ's,
> 
> While I have never had the need to fiddle with this, I am pretty sure
> that the nvidia configuration gives you the ability to do all sorts of
> tweaking with its performance. But I guess that this would also depend
> on whether the nvidia card you are using is of the modern era or of the
> Edwardian era :-) .

GForce 9400 GT, probably on its last legs, the OEM fan died yonks ago, and 
the bigger one I put on it a year ago is now occasionally making dis-
agreeable rumbles. What era that is is up to you. :)
 
I was on their forum a couple of years ago.  There is so much bureaucracy 
involved in both signing up, and logging in each time, and any answers 
apparently have to be cleared by legal so its 2-4 days slow, and the 
eliding of useful information from the answer was as obvious at times as a 
highway billboard.  Being from the Iowa farm country, their forum is to me, 
somewhat less useful than the teats on a boar hog.

> Here are a couple of screenshots to show what I mean:
> 
> http://susepaste.org/91764328
> 
> http://susepaste.org/22234584
> 
> >   AND is capable
> > 
> > up updating the install despite finding traces of an old install by
> > deleting and overwriting the old files with whatever its trying to
> > install this time,  aka a --force option, then I might consider its
> > use again BUT NOT on a machine that is actually running what can be
> > dangerous, higher powered machinery.
> > 
> > That of course is up to nvidia.  If they want the whole market, they
> > will fix that, if not, sorry not on my machines.
> > 
> > Cheers, Gene
> 
> BC


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Software is like sex, it's better when it's free.     -- Linus Torvalds