Possible interesting QT/hardware issue for multimedia developers

[Ziggi]

Hi !

I post is here as many of you invest in now hardware from
time to time, so hardware-related problems influencing
multimedia development are important.

A few days ago I posted about my CD/DVD recorder
related problems and now it's another - probably more
important issue.

Please find below my message posted to Apple forum.

Ziggi
--------------------------------------------------------
--------------------------------------------------------
Hi !

This might be some system related problem but I post here,
perhaps somebody has any idea what to do...

I am a multimedia developer, so QT is a must have for me.
Recently I assembled a new PC:

MSI K7D Master-L mobo, double Athlon MP 2800+,
NVidia 4400Ti, 1GB Kingston DDR RAM, Adaptec RAID
controller and two stripped Seagate 120GB HDDs.
All is running Windows XP under NTFS file system.

It is running really nice except QuickTime. The problem is
pretty strange. QT 4 is running well but starting from QT 5
(I checked v. 5.05) up to the lates 6.4 release playing Sorenson
or MPEG4 compressed movies (like the sample mov coming with
QT installation) hangs the whole workstation completly so that
hard (chasis button) reset is the only escape.

And now is an interesting part: the crash only happens in case the movie
is being played from HDD. In case it is sitting on a removable media,
or a network drive or ramdisk there is no issue. But in case the movie
is sitting on HDD - crash is 100% repeatable - for the 'sample.mov' it
happens nearly exactly in the middle of the clip.

This is of course very frustrating as the crash issue concerns my
Macromedia Director projects as well as many other ones, so I am
nearly unable to do my regular job !

I tried all the QT video and audio settings but it seems the problem
is in fact laying somwhere else - it looks like some serious conflict with
the system hardware layer.

I have browsed Google and I can see a lot of posts concerning QT related
problems specific to AMD platform I was not aware of. Shouldn't Apple
take it under consideration while designing its software ???

Please comment as this issue is of critical importance to myself.

Thank you,
Ziggi



--
Sincerely,
Ziggi

[Robert Tweed]

"Ziggi" <admin@pm-studio.pl> wrote in message
news:bqahrl$6c4$1@forums.macromedia.com...

>
> And now is an interesting part: the crash only happens in case the movie
> is being played from HDD.

Hmm, that makes me think of one thing immediately: your RAID setup. Is it
onboard or a separate card? The first thing to look for is updated Windows
drivers, and secondly updated firmware. The most common cause of disk
problems is bus timing problems, which are because the software or firmware
does not allow enough wait states for your CPU speed, with whatever the
latency of the device is.

Generally, the hardware will work OK with whatever CPUs were common when the
hardware was first released, but it it common for much faster CPUs to become
commonplace shortly afterwards. If your motherboard or SCSI adaptor is
relatively new then it is quite conceivable that fully working firmware does
not even exist yet.

NB: It is also particularly common for this type of problem to occur with
CPUs that are not made by Intel, because the initial firmware is usually
designed for Intel, and the different timings of other processors can throw
it off a lot more than just simple changes in clock speed. The fact that you
see this problem with an Amd processor is therefore not surprising at all.

Typically, heavy datastreams like video can put the disks under more stress
than usual and show up hardware problems that do not occur with data that is
not transferring quite as quickly. I've seen systems with your exact
symptoms many times and the problem has always been due to effective
(unintentional) overclocking of the I/O hardware.

You should not blame Apple for this though, its just that their codec is
pulling data from the disks faster than any other codec you've tried (you
could probably find others if you looked hard enough). In fact, the very
fact that this problem does not occur intermittently is a bonus for which
Apple should be thanked, because otherwise these problems can be extremely
hard to fix - the first step in fixing it is to reliably reproduce the
problem.

One brute force way to fix this type of problem is to reduce the CPU
clockspeed, especially the FSB speed. You might be able to avoid that if
your motherboard has jumpers or BIOS options for any of the following: FSB
to PCI clock divisor and I/O wait states. PCI is actually only specificed up
to 33MHz, but most motherboards will overclock it beyond this by default,
which can wreak havok with devices. Also check the SCSI BIOS for similar
hardware options, particularly anything to do with latency and wait states.

Note that if your RAID controller uses an onboard chip then it may not be on
the PCI bus anyway (onboard chips are generally specified to higher clock
speeds than PCI), so in that case options relating to PCI would probably
make no difference - however something vague like "I/O" might help, and
might not - you'll just need to experiment. The next thing I'd look for with
an onboard controller is a Flash BIOS update - you may also need a separate
SCSI BIOS update, but that depends on the type of BIOS.

As an experiment, the first thing I'd do is to clock the processor down as
slow as possible. Then, if that fixed the problem, I'd start tweaking CMOS
options until I [hopefully] found something that worked at full clock speed.

BTW, don't run your CPU clocked down for too long as modern CPUs can
apparently develop "memory" of slower speeds that can make then less
reliable when clocked back up to full speed. This is not something I've ever
seen in practise, but I've read about the theoretical possibility so I'd be
wary of running a downclocked CPU for too long. It can't be a major problem
though, because otherwise speedstep processors would be inherently
unreliable. I wouldn't worry about running downclocked for a few hours or
whatever.

- Robert

[Ziggi]

Thank you Robert for your excellent advice but please let me
make an addendum:

The "total freeze" also occurs in case the quicktime movie clip
is started in a "paused" mode. Than, with a right arrow key
I can 'tap' and effectively 'scrub' thrugh the clip.
So, It's going well foreward and backward untill some
fixed and well defined point of the clip is reached.
In case of the 'sample.mov' this is exactly the moment
when "smoky" gray "QuickTime" letters start to appear
below the blue QT logo - I would say in the middle of the clip.
At this point the whole thing get frozen.

I don't see here any RAID related problem as the movie is
not in the play mode. It is rather served frame-by-frame.
Isn't it ?

So what is your idea ? - I am lost...

Ziggi



--
Sincerely,
Ziggi

[Ziggi]

BTW - my Adaptec RAID is a PCI card...
and there is no problem with Windows media
or even with avi clips (like Premiere samplers)
being played with QuickTime !

The problem seems to be ".mov" related...

Ziggi



--
Sincerely,
Ziggi

[Robert Tweed]

"Ziggi" <admin@pm-studio.pl> wrote in message
news:bqapmq$hnh$1@forums.macromedia.com...

>
> I don't see here any RAID related problem as the movie is
> not in the play mode. It is rather served frame-by-frame.
> Isn't it ?

I'm thinking it's likely that Quicktime is requesting the data in chunks -
after all it probably does not know exactly how much data is required per
frame, so it will have a read-ahead buffer of a particular size. It is
probably the size of chunk it's requesting that's causing the problem. If
it's slightly larger than other codecs it could be forcing the harware to
make more I/O requests in rapid succession, which if the latency is longer
than the drivers are allowing sufficient wait states for, is where the drive
will lock up and crash the system. Maybe that specific frame just sits
between sectors or something, forcing even more data to be read than usual?

Of course, this is just a theory, but it's an educated guess based on having
seen very similiar problems many times before. Admittedly, I usually saw the
problem with EIDE, which has PIO burst modes (and those are especially
problematic), but I daresay modern SCSI isn't much different. The similarity
of the symptoms means that this is the first place I'd look.

After all, the fact that it works properly with a RAMdisk tells you that
it's not a simple compatability problem with the Amd instruction set or
whatever - it's therefore definitely got something to do with the I/O
hardware. And that usually means either: the controller or drive is
physically buggered; or the port is being accessed quicker than its hardware
latency allows. The latter is the usual cause, because its really a software
problem, though generally classed as a hardware issue (I suppose firmware
problem would be the most accurate description).

To explain how this works at the driver level, what happens is when you read
port X, you must then leave a delay of Y nanoseconds before you can access
the port again. This delay is must be longer than the latency of the
hardware, which might be related to the drive rotation speed, or other
factors that have nothing to do with the clock speed of the bus. Obviously
the drivers are written to keep the delay as close to latency as possible,
otherwise the hardware can appear slower than it really is (or in a worse
case scenario, incoming data might be missed). However, if the delay is too
short then best case scenario, you get wrong data; worst case, you get a
system crash. Since the delay timing is linked to the CPU speed, if the
firmware doesn't recognise the CPU, you get incorrect timings. This is
really surprisingly common.

JOOI, what happens if you try to copy the entire file to another directory?
Does that crash the system? I'm just curious about whether the problem is
totally Quicktime specific or not. Also out of interest, having copied the
file, does the copy crash at the same point? Still, neither of these would
affect my judgement that it is most likely an I/O latency problem, because
these things can be quite weird, I'd just be interested to know how specfic
the problem is. If the copy produced the same results, I'd be inclined to
copy it to something on the IDE channel (either a hard drive or a CDR) and
see if that acts the same way or not. If you have a timing problem on the
SCSI bus, it's highly unlikely to be present on IDE as well (unless you are
ridiculously unlucky, as it would be pure coincidence).

- Robert

[Robert Tweed]

"Ziggi" <admin@pm-studio.pl> wrote in message
news:bqaq0b$i65$1@forums.macromedia.com...

> BTW - my Adaptec RAID is a PCI card...
> and there is no problem with Windows media
> or even with avi clips (like Premiere samplers)
> being played with QuickTime !
>
> The problem seems to be ".mov" related...

This is, to my mind, mostly irrelevant. Driver compatability problems can
sometimes appear to be very application specific. For instance I've seen
systems crash fairly consistently in Word, but work perfectly in everything
else - the problem being due to the video driver, but for some reason only
Word was using the driver in such a way as to demonstrate the problem.

The last time I saw a problem like yours, the system worked perfectly with
everything except a *single* MPEG file. Other video files of the same format
worked perfectly, but that one crashed the system quite consistently. It
turned out to be the disk latency problem I have described, and was due to a
Cyrix processor that was not properly supported by the IDE drivers. Clocking
it down solved the problem, as did updating the drivers when they became
available.

With a PCI card I'd be very suspicious of the FSB to PCI ratio, especially
with an Amd processor (which often have unusual FSB speeds). There is a
clock divisor that converts the main motherboard FSB to a suitable clock
speed for PCI. This divisor is supposed to result in 33MHz or lower, but a
lot of PCI devices will run perfectly well at 40 or 50MHz, so
motherboards/BIOSes tend to be quite lax about enforcing this limit.
However, if you happen to be unlucky and your card is on the lower end of
the manufacturing tolerances then it may simply not work at these speeds.

It isn't always very obvious what speed the PCI bus is running at, but there
should be a jumper, a DIP switch, or a CMOS setting to change it. If it says
something like CLK/8 then (if your CPU has a 266MHz FSB) that is correct. If
it says CLK/4 then you are running your PCI cards at 66MHz - double their
rating. Normally you have options for a few different CLK/n values and a
fixed 33MHz option (which is usually safest), and sometimes a 25MHz option
(which might be useful if 33MHz is still giving problems). The CLK/n
settings are normally useful for overclocking, but for some reason they tend
to be the default setting on many boards.

- Robert

[Ziggi]

Woewowwow :-/''

The mark above express my current feeling...

Ok, let's see what will happen. First of all
I must say there is a motherboard bios update
in the MSI page telling exactly:

"Supports AMD MP 2800+ in correspondance with AMD
web site recommendation"

Whatever that means I believe I should start here...

I don't like meddling in Bios... whatever intercepts
the flashing process the whole game is over untill the next
mobo... (forget bios chip exchange in Poland... you never
get one).

Then eventually Adaptec RIDE bios.... what's the hell !

But it seems the first natural step... but that hardware/driver
related issues suck...

Thank you Robert,
Ziggi



--
Sincerely,
Ziggi

[Ziggi]

For your info...

This is just a brand new machine just assembled...

I sit for a few days and make "general cleanup" of my data.
So, through about 4 days I archived about 40 GB of data
from different sources on my new RAID matrix just in a purpose
to write them all down on my new DVD-R :-//

You see - DVD burner doesn't work as expected, so all the
stuff is just on these two striped Barracudas waiting for miracle.

I HAD NO SINGLE I/O problem doing all of this !!!

The problem is strictly QT related and moreover... only .mov
related. This is pure nonsens.

Ziggi



--
Sincerely,
Ziggi

[Robert Tweed]

"Ziggi" <admin@pm-studio.pl> wrote in message
news:bqb12b$7h$1@forums.macromedia.com...

>
> This is just a brand new machine just assembled...

The usual cause of problems :)

> I HAD NO SINGLE I/O problem doing all of this !!!
>
> The problem is strictly QT related and moreover... only .mov
> related. This is pure nonsens.

Like I said, these things can be weird - just because you don't get an I/O
problem during normal file copying does not mean you do not have a hardware
related problem. It's simply a case that the one bit of software is
performing a very *specific* I/O operation that happens to be outwith the
operating specifications of the hardware.

Trust me, I spent 7 years diagnosing problems like this, many of which were
a lot stranger and hard to reproduce than this. Even without seeing your
machine I can be pretty certain that I'm right about the cause of the
problem, just from what you've told me. There are other, much less likely
possibilities, but the only way to find out would be to physically test your
hardware by doing like-for-like exchanges and whatnot. Its definitely not a
purely software problem because the same software works with different
hardware.

- Robert

[Robert Tweed]

"Ziggi" <admin@pm-studio.pl> wrote in message
news:bqb098$qgm$1@forums.macromedia.com...

>
> I don't like meddling in Bios... whatever intercepts
> the flashing process the whole game is over untill the next
> mobo... (forget bios chip exchange in Poland... you never
> get one).

It's very unlikely the flashing process will be interrupted. Firstly though,
make absolutely sure you've got exactly the right files (sometimes it's a
good idea to check the motherboard model number, which is printed on the
board itself, don't go by any other indications as it is quite possible you
could have the wrong manual or whatever - the model number should also
appear on the BIOS information page - usually in the bottom left hand corner
of the screen hidden in among various other numbers)

Secondly, make absolutely sure nothing interrupts the flashing process, -
that means making sure the power cable in in very securely and don't do
anything that could cause the power to be disconnected, or press the reset
button, etc., during the Flashing process.

Only once have I had a BIOS flash fail on me, and that was due to a hardware
incompatability. Therefore, my final recommendation is this:

Disconnect all unneccesary drives and remove all cards from the motherboard
before doing the update. This means taking out the RAID controller, any
modems, network cards, etc. and leaving only the floppy drive (or whatever
drive you are using to boot up and do the Flash update).

That last step should not be necessary, but since you are only doing the
update due to an apparent hardware problem, it might be prudent anyway. The
time it failed with my system was because (believe it or not) a video card
was interfering with the interrupt controller and causing I/O operations to
fail - the disks only worked properly with a different video card. The
updated BIOS also solved the problem, but when I tried to update the BIOS
with the usual video card in, it failed - for other systems I had to use an
older video card to do the update (btw it is extremely unlikely that you
have this sort of problem, before you ask ;-)

In the unlikely event that you do end up with a dead BIOS, the procedure is
normally to send it back to the motherboard manufacturer in whatever country
the manufacturer is based. They will then send you back a new one. I had to
send mine off to Sweden IIRC, so it took a couple of weeks to get a
replacement, but it did arrive eventually. To save time, you might be able
to find somewhere with the right type of chip reader/writer to restore the
BIOS image without the motherboard. Places that sell pirate games, chip
playstations and do other dubious things usually have all the necessary
hardware for this sort of job, so maybe finding a disreputable computer shop
would be better than finding a reputable one ;-)

- Robert

[alchemist]

> Only once have I had a BIOS flash fail on me, and that was due to a
hardware

> incompatability.

Hmm... Can't begin to imagine the time I'd need to remove all those cards
and drives you recomment for every mobo/vga/other firmware update I've
performed till now. In (should be) well above 50 of those never had any
casualties. And can't say I've been very carefull during the process - the
luxury of UPSs has been a relativelly recent addition. However, can't recall
issues like the ones Ziggi mentions to have been solved after an update.
Usually, the major fixes are being included in the readme files of the bios
update package.
As for the rest, too tired at the moment to read eeeeverything you wrote,
but to me it seems like a video driver or memory issue. Also, checking the
DMA state of the controler and a possible driver update for the controler
wouldn't hurt - not much into on-board raid controlers, so...
A second thing I would try would be reading from a disk on another bus.

> MSI K7D Master-L mobo, double Athlon MP 2800+, ...

Nothing to do with personal preferences, but, since you mentioned AMD and
Premiere, at least according to my (brief) tests, Athlon machines are not
the ideal platform for video editting. No crashes or anything, just that the
performance compared to Intel machines on progs like after effects and 3Ds
is.. well... to be avoided.
A p4/2.66 seemed to be rendering about 30% faster than an xp2700+ on w2k.
Haven't made any tests since the -necessary for premiere pro- xp 'upgrade',
but i'll try to find some time to do so, since this was quite a surprise, to
say the least.


"Robert Tweed" <robert@killingmoon.com> wrote in message
news:bqb8vb$9e8$1@forums.macromedia.com...

> "Ziggi" <admin@pm-studio.pl> wrote in message
> news:bqb098$qgm$1@forums.macromedia.com...

> >
> > I don't like meddling in Bios... whatever intercepts
> > the flashing process the whole game is over untill the next
> > mobo... (forget bios chip exchange in Poland... you never
> > get one).

>
> It's very unlikely the flashing process will be interrupted. Firstly

though,

> make absolutely sure you've got exactly the right files (sometimes it's a
> good idea to check the motherboard model number, which is printed on the
> board itself, don't go by any other indications as it is quite possible

you

> could have the wrong manual or whatever - the model number should also
> appear on the BIOS information page - usually in the bottom left hand

corner

> of the screen hidden in among various other numbers)
>
> Secondly, make absolutely sure nothing interrupts the flashing process, -
> that means making sure the power cable in in very securely and don't do
> anything that could cause the power to be disconnected, or press the reset
> button, etc., during the Flashing process.
>
> Only once have I had a BIOS flash fail on me, and that was due to a

hardware

> incompatability. Therefore, my final recommendation is this:
>
> Disconnect all unneccesary drives and remove all cards from the

motherboard

> before doing the update. This means taking out the RAID controller, any
> modems, network cards, etc. and leaving only the floppy drive (or whatever
> drive you are using to boot up and do the Flash update).
>
> That last step should not be necessary, but since you are only doing the
> update due to an apparent hardware problem, it might be prudent anyway.

The

> time it failed with my system was because (believe it or not) a video card
> was interfering with the interrupt controller and causing I/O operations

to

> fail - the disks only worked properly with a different video card. The
> updated BIOS also solved the problem, but when I tried to update the BIOS
> with the usual video card in, it failed - for other systems I had to use

an

> older video card to do the update (btw it is extremely unlikely that you
> have this sort of problem, before you ask ;-)
>
> In the unlikely event that you do end up with a dead BIOS, the procedure

is

> normally to send it back to the motherboard manufacturer in whatever

country

> the manufacturer is based. They will then send you back a new one. I had

to

> send mine off to Sweden IIRC, so it took a couple of weeks to get a
> replacement, but it did arrive eventually. To save time, you might be able
> to find somewhere with the right type of chip reader/writer to restore the
> BIOS image without the motherboard. Places that sell pirate games, chip
> playstations and do other dubious things usually have all the necessary
> hardware for this sort of job, so maybe finding a disreputable computer

shop

> would be better than finding a reputable one ;-)
>
> - Robert
>
>