Jump to content
HWBOT Community Forums

The official Old School is Best School Round 5 thread.


Massman

Recommended Posts

  • Replies 79
  • Created
  • Last Reply

Top Posters In This Topic

So, that means you can confirm the crash at 24h or not? "Watched it close" seems to suggest that, but frankly... more direct confirmatio might be need.

 

I run the v1.6 ... it goes faster, as before K5 PR75 @ 90MHz need 68min per loop, now 59min is enought... interesting. Maybe it run with the part of ram, that goes on 2 ranks dimm, instead of the 1 rank one? Dunno. But I'm, of course, nowhere near the end...

Link to comment
Share on other sites

So, that means you can confirm the crash at 24h or not? "Watched it close" seems to suggest that, but frankly... more direct confirmatio might be need.

 

I run the v1.6 ... it goes faster, as before K5 PR75 @ 90MHz need 68min per loop, now 59min is enought... interesting. Maybe it run with the part of ram, that goes on 2 ranks dimm, instead of the 1 rank one? Dunno. But I'm, of course, nowhere near the end...

 

Well, I guess so. I didnt get an error on WinXP but it just closed down instead. I took a risk at trying to end it with a nice time of 23h 59min XX seconds but it backfired and superpi just closed down instead so my guess for the crash is that the end time was 24h 00min XX sec which lead to a crash or that it just crashed the second it reached 24h.

 

Im just over 19h into the run with 1.6 now so will know how it plays out in 5 hours.

Link to comment
Share on other sites

When I use Windows 2K and very old HW (486DX4), after 24 HRS SPI is just closing down and I can see desktop. (explorer.exe is not working so I can see only the background colour).

 

When I used Windows XP and K5 I think I remember my first not optimised platform tests and non-OCed K5 it crashed and so I wanted to make it more stable so I added more HDDs (1 for OC, 1 for pagefile.sys, 1 for SPI calculations), then OCed CPU and it did <24 HRs. Back in the day I maybe didn't know about the 24 Hour limit, but I didn't pay attention to this...

Link to comment
Share on other sites

And sadly I did not took a photograph using camera from the amazingly fast run - 23 loop was at 23h 43min! IMHO good for 90MHz K5 PR75... ;)

 

Now this is interesting. I just assumed that since 1.6 was slower than 1.5 on new stuff that it was just plain old slower. But if it's faster on old stuff, well, I guess I have some rebenching to do!

Link to comment
Share on other sites

ludek - Yep, and you did well with the K5 PR75, overclockead at 100MHz ;) I cannot match your score at 90MHz, no way.

 

On WinNT you can see the crashed app for short period of time, then it autoclose down and Dr.Watson does his work. If I optimize Win more (read, under 10MB :D ), then I disable Dr.Watson and I will also not see a thing... ;)

 

(time to look for possibility of some undocumented Asus TXP4-X voltage options to get more that 3.5V, because at 3.5V @ 99/100MHz mine K5 PR75 just post (partly) ... and that it is...)

 

 

 

Dead Things -

I just assumed that since 1.6 was slower than 1.5 on new stuff...

 

I was very surprised to see that the loop get under 1h and each loop cut progressively from the time down and down... But I did not managed the score under 24h, hence crash come. These versions won't be much different, because both versions crashed badly, lol. The different size is mainly due to different exepacker.

Edited by trodas
Link to comment
Share on other sites

I have to sadly report, that SuperPi v1.6 Techpowerup mod crash at 24h mark for 32M test too:

 

Super_Pi_1_6_24h_crash.jpg

 

That suxx. And sadly I did not took a photograph using camera from the amazingly fast run - 23 loop was at 23h 43min! IMHO good for 90MHz K5 PR75... ;)

 

I wasnt home when it ended, but the 24h+ run on 1.6 sure has crashed for me aswell now after 24h plus. So confirmed that 1.5 and 1.6 cant run longer then 24 hours id say.

Link to comment
Share on other sites

lanbonden - thanks for the confirmation.

 

 

Dead Things -

I guess I have some rebenching to do!

 

Well, for you, I compared the 1.5 and 1.6 versions on AMD K5 PR75:

 

SuperPi 1M v1.5: http://hwbot.org/submission/2982984_ (26:32.871)

SuperPi 1M v1.6: http://hwbot.org/submission/3001139_ (26:14.634)

 

...but meanwhile I optimized the WinNT more, so it is a good question, if the speed are really faster with v1.6. I'm sure that for 32M tests is the v1.6 had notably faster run (about 8 to 12min per loop), but since my TXP4-X memory system exclude it from drawing any real conclusion from it.

 

The reasons:

- Asus TXP4-X support maximum 256MB of ram, but I have it running at 384MB of ram

- the rams are not even - first stick have 1 rank and 1 side, 128MB capacity. Second have 2 ranks, 2 sides and 512MB capacity, from witch 256MB is used

- the IDE drive fail (mostly) to work with DMA on, reducting the speed to snail average 4MB/sec (with the K5 PR75) with high CPU load and when it run with DMA on, the speed-up is dramatic! ( DMA off: http://s13.postimg.org/n5y9xs7av/13_G_Seagate_P90.png DMA on: http://s22.postimg.org/dt20a7sm9/32_G_CF_Sandisk_karta.png )

- 512k L2 cache onboard, but it (due to chipset limitations working with L2) can cache only 64MB of ram...

 

So, you have no guaranetee, why the run was faster. It was, but why is the question. I would first repeat this test. There also might be a difference on how the executable packer wreck the memory management on unpacking the executable. That could play a key role too, but we just did not know for sure. Little bit more testing will go a long way :)

Link to comment
Share on other sites

@trodas

You can put higher multiplier CPU and do your unofficial frequency. It could be interesting eg. AMD K6-III @30 MHz SPI1M -->> ~1day :D

(or maybe 30 MHz is too fast to do 1 day, then look for 2x cpu or even 3x)

 

//I mean please do this and we will be able to see if only 32M combination with slow CPU is causing problem or if 1 MB is also crashing. If both crash then we can say that it is caused by SPI version, not 32MB option... You know what I mean. I could check this if I had "unofficial" settings :) //

Edited by ludek
Link to comment
Share on other sites

lanbonden -

did you try to run it slower then 24h on a x64 OS?

 

Nope, please test it. I did some testing in the possibility of slowing-down more modern CPU's, but I failed completely. For some reason, when I disable L1 cache (L2 does not have that big effect AND things work w/o L2 normally, even SuperPi), SuperPi crash for me. Always. It run very slow and then (5-6 loop for AMD, 9-10 loop for P4) crash.

 

Most these old board can disable L1 and L2 caches, some even the SSE instructions support and even that disabling all but L1 does not affect the performance much, disabling L1 is "super-killer" of performance. For the reference, all these machines can do SuperPi 32M w/o fail or crash or any other problems, all the computers have replaced their original bad caps to good ones and all these computers are 100% stable and I can run on th SuperPi 32M tests repeatedly w/o any trouble... BUT!

 

Here we come. I got starting scores 12h 28min per loop, or even 17h 59min per loop:

 

Super_Pi_12h_28min_per_loop.jpg

(PCchips M810LR (SIS 730) 11x100MHz AXP Barton SDRAMs 3-3-3-6)

 

Super_Pi_17h_59min_per_loop.jpg

(Jetway V266B (KT266A) 5x100 AXP-M DDR 2-2-2-5)

 

That would produce (18hx24) a 432h long benchmark (18 days) - but it crashed on the 24h limit also.

 

However, and that is where things get really bad, it always crash. Sooner or later it crash on any machine with disabled L1 cache in bios I run it. A good example is P4 3.4GHz CPU that fail w/o caches too:

 

Super_Pi_crashed_when_run_without_caches.png

(MSI PM8M3-V (VIA P4M800) 17x200 Pentium 4 DDR 2-3-2-5)

 

(notice the crash time!)

 

I would once again stress, that the machines are completely stable, there is no way that the error is hardware related. Not when it happen like 10x times. Since all these tests failed, because they go over 24h, then this 24h bug is completely and entierly confirmed. Please someone test on 64bit OS. And maybe use other slow-down methods. For me, the cache off come as the easiest thing to do...

 

Yes, all these tests are 32M runs. I let run 1M overnight w/o caches (600MHz Duon + 4.2GHz P4) and we see what happen.

 

And did you start that 1M run yet?

 

On the 10.7MHz CPU? Nope. I was banging my head currently on how to give the Asus TXP4-X maniboard a fast HDD. I get a PATA to SATA adapter, SanDisk 120G (must be to be under the 128G limit with patched bios) Ultra II SSD and now I figuring out how to make it all work. It does not. The SSD is well detected during POST and things seems to work (I can install ANY operating system on it, WinNT, WinXP...) but it does NOT BOOT from it:

Asus_TXP4_X_trying_SSD.jpg Asus_TXP4_X_trying_SSD_2.jpg Asus_TXP4_X_trying_SSD_3.jpg

(SanDisk Ultra II 120G (SDSSDHII-120G), PATA to SATA bi-derectional adapter from Gembird, chipset JM20330, should do hot-swap for non bootable devices)

 

I tried many disk-setup programs, from old fdisk thru Windows setup to Acronis on Hiren Boot CD 8.6 (my favorite Mini Tool Partition Wizard Pro BOOT CD (allign SSD) does not work on the board... and AMD K5 PR75 in it right now), yet it always fail to boot from the SSD. I have no idea what to do and I very much want to get fast HDD operations... so I trying to push for this instead of having the machine bogged down with 24h limit test... Maybe later, when I figure this crap out. That is second time when PATA - SATA conversion proved unbootable for me. First case - Dell OptiPlex GX110. Same result, different convertor used. Working, but NOT booting...

 

Sigh.

Edited by trodas
added info
Link to comment
Share on other sites

ludek -

You can put higher multiplier CPU and do your unofficial frequency. It could be interesting eg. AMD K6-III @30 MHz SPI1M -->> ~1day (or maybe 30 MHz is too fast to do 1 day, then look for 2x cpu or even 3x)

 

The only unlocked CPU for multiplier settings I have for the TXP4-X is the AMD K6 III+. That (together with the AMD K5 PR75 CPU) refuse to post at 7.14MHz settings. One bios patcher/moder suggested, that it might take the clock as test one and ignore it. Intel does not support that test mode, so it works just right away... Dunno if that is the reason, but I found no AMD CPU yet that can work at 7.14MHz FSB. AND I have no one other Socket 7 CPU to test... Donations accepted for the cause, of course.

 

I bought Pentium OverDrive 200 MMX, but the person who have to send it did not yet confirmed even going to the post office, so... that will took some time, I'm affraid, to get there.

So while in teory it should work, it does not. No idea why and except some change in bios (test mode to normal mode?), there is a little hope that it will run at 7.14MHz. Besides, lowest K6 multiplier is 2. A bit high for me :)))

 

I mean please do this and we will be able to see if only 32M combination with slow CPU is causing problem or if 1 MB is also crashing.

 

It is unnecessary, it will crash over 24h for sure, but I let the Duron 600 run w/o caches for the 1M and we see. If it piss me off by going too fast, then I will slow it down to 200MHz: http://valid.x86.fr/kfqjxs ...AND kill the caches :) That should do it easily.

I thought that I can do it on the Pentium 4 at 4.2GHz, but it turns out I cannot. The lame ASROck bios does not support cache off option and Windows compatible version of program to disable the cache(s) is not ready yet to roll, so sorry. Only one computer is dedicated to over 24h SuperPi 1M test now.

 

I more waiting for some news from Fugger. I want fix for this error :) So with v1.7 I could be the first to break 24h on SuperPi :)))

 

If both crash then we can say that it is caused by SPI version, not 32MB option... You know what I mean. I could check this if I had "unofficial" settings

 

Well, I have the SuperPi already unpacked and therefore editable:

Super_Pi_mod1_5_XS_unpacked_editable.jpg

...so I could take a look at the code, but it did not seems to have any possible "hidden options" at all. Unpacked size is 579 504 bytest after correctios on resource sizes (before it was 764 416 bytes). The depacker is called there:

0041005E >  6A 00           PUSH 0x0
00410060    E8 7BFC0100     CALL super_pi.0042FCE0

...and when I started more that hour ago the 1M calc, w/o the caches are the CPU that slow, that unpacking the 100k packed exe took about 15 sec or something. Maybe I should give the unpacked one a chance, but that version is not for public usage, because it is packed for good reasons...

 

 

 

lanbonden -

Ok, I tried to slow my socket 754 rig down but I cant get it slower then ~3.5h for 1M, so only a slowdown of 250x

 

3,5h for 1M? Nah, that is too fast :) What do you used to slow SuperPi down? For me is best killer the L1 cache. Maybe I should give CPU-Z stress a chance too, if the cache is not good enought :) Worked great for me on the GPUPI challenge :)

 

Ill try the part with 32M on a x64 OS instead, just need to decide on what bench ssd/hdd to sacrafice for a future reinstall...

 

Please do.

Link to comment
Share on other sites

Guys, sorry for my lame mistake, fdisk /mbr fixed the boot issue, so I get the SSD running in my Asus TXP4-X mainboard. That is a good thing. Install went fine even at 83MHz FSB (witch give 41.7MHz PCI bus clock) using Pentium 90 @ 125MHz.

 

However that is all for good things. Bad thing is, that the SSD will not using DMA at all and the speed is accordingly limited by CPU - see 93.3% CPU usage - to 7.2MB/sec:

 

HDtach_no_DMA_7_2_MB.jpg

 

This is laughable for SanDisk 120G Ultra II SSD, even run thru the adapter that support SATA (1) only...

 

...

 

I would like to mention that ONCE (just once!) I get the DMA running using PATA to CF adapter and that give me on same machine speed around 24MB/sec. With around 20% CPU usage. That might looks a big high, but remember that we are talking about Pentium 1 system, not i7 machine... :)

 

32_GCF_Sandisk_karta.png

 

So, anyone have any ideas / solutions for that DMA failure? Anything that could be done there? Do I need some install for the i430TX chipset to get the DMA working?

Link to comment
Share on other sites

lanbonden -

3,5h for 1M? Nah, that is too fast :) What do you used to slow SuperPi down? For me is best killer the L1 cache. Maybe I should give CPU-Z stress a chance too, if the cache is not good enought :) Worked great for me on the GPUPI challenge :)

 

Please do.

 

Im using a software fake load that lets me set the load betwean 1-99%, It works suprisingly well couse if I set it at 96% SuperPi for example runs very close to the calculated speed it should at 4% CPU speed.

 

Combine this program with fsb reduced by 50% and another load like GpuPi on high prio in the background and its get very slow.

 

Your tips about killing the L1 cache would probably make that superpi 1M totaly possible tho!

 

Im ~21.5 hours into a test on Win XP x64 now aswell, but really cant see it matering?

Link to comment
Share on other sites

Well, my Duron let me down. At 200MHz (34.5x6) w/o caches it make the 1M test in about 2h, witch is pretty quick. I stoped it at loop 16 or so, when it is at 1:40... because that suxx. I got screen, but not on my computer right now.

 

So I try another approach. Again no caches + ~200MHz + load by the new CPU-Z. Sadly I forget that new CPU-Z mostly freeze on the MSI K7TM Pro, despite the mobo run stable for nearly month for the Aquamark score 2... it freezed, witch make me just switch it off and leave it alone. Pissed at CPU-Z bugses...

 

...

 

Today I give it a chance. Again no caches, again ~200MHz, but now a SuperPi 32M for load. However when I set the priority to Realtime, my mouse stop working, lol ... no comment. Setting priority of the 32M background task to High cause it took ~3.5h for just preparing the memory for the loop 1, so... that *WILL* definitively took the 1M test (lowest priority) over 24h.

But dunno, if I manage at least few pases, because the 1M test did not print anything in it's window for ~3.5h...

 

Maybe I overdid it?

Link to comment
Share on other sites

The 32M on x64 run is completed, was lucky to get run 22 to finish at like 23h 58min 56seconds or something so picked up the phone to catch it on film. Was really suprised how it didnt crash instantly this time but almost at 24h 1min into the benchmark.

 

So x64 OS not working either confirmed.

 

We just need 1M run on 1.5 or never to reach 24h now so good luck with your current run.

Link to comment
Share on other sites

The 1M run still did not even show "The initial value finished" and it is running for hours now... so I quess that I overdid it. No change on the 32M hi-priority one as of yet. So it will be very bad, there will be (like on the tests above) just few time infos and then crash...

 

Good to hear that the crash is confirmed on 64bit OS too, but I did not expect any different.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...