Hyperion Entertainment Message Boards

nexus wrote:

xenic wrote: "Interresting" isn't the term I would use to describe my feelings if I find out I bought a system that must be crippled down to the equivalent of a system that cost hundreds less.

Hasn't DAX stated that also a (good) CPU Fan solves the problem? If so, adding a Fan is not like having to 'cripple down' your system.
nexus

My response was to cha05e90 suggestion that switching to a slower speed would be interresting. My response was intended to idicate that if that's the only solution, I would not be happy. Read my original post. It doesn't say that my SAM must be slowed down to solve the problem; it says "IF it MUST be crippled" and not that other solutions (like a fan or software change) may not work.

Would you be happy "IF" you must stand on your head to make you Amiga work? Of course not, but notice that I used the word "IF" and didn't say that you do have to stand on your head. Good grief. Lighten up.

Maybe its time to communicate with Acube outlining the problems observed .

xenic wrote:

nexus wrote:

xenic wrote: "Interresting" isn't the term I would use to describe my feelings if I find out I bought a system that must be crippled down to the equivalent of a system that cost hundreds less.

Hasn't DAX stated that also a (good) CPU Fan solves the problem? If so, adding a Fan is not like having to 'cripple down' your system.
nexus

My response was to cha05e90 suggestion that switching to a slower speed would be interresting. My response was intended to idicate that if that's the only solution, I would not be happy. Read my original post. It doesn't say that my SAM must be slowed down to solve the problem; it says "IF it MUST be crippled" and not that other solutions (like a fan or software change) may not work.

Would you be happy "IF" you must stand on your head to make you Amiga work? Of course not, but notice that I used the word "IF" and didn't say that you do have to stand on your head. Good grief. Lighten up.

@ChrisH
I'm not much complaining as I'm trying to help in truth, quite frankly I can live with the CPU fan (noise levels are very low) the system is stable albeit performing a tiny bit worse in some regards and a tiny bit better in others.

That said I will try to explain from another angle the same concept: what I suspect is that the overheating isn't caused by something normal nor beneficial. If that was the case and if it was "just" my CPU sample being "borderline", then there should be methods to force the same behavior regardless of kernel, it would be sufficient to start running the most taxing stuff and add up until eventually the weak borderline CPU is so overheated it freezes.
There should be a point in practice, when the load (even if using 53.12) is so high that the borderline CPU sample has to give in, but in truth, there isn't, even with 10 times the load, when using 53.12, it only gets slower and slower and never freezes. So what is exactly causing such overheat when using kernel 53.22, high levels of heat although there is 1/10th of the load and and no tangible benefits?

Might be helpful to find out, even for future developments.

DAX wrote: if it was "just" my CPU sample being "borderline", then there should be methods to force the same behavior regardless of kernel, it would be sufficient to start running the most taxing stuff and add up until eventually the weak borderline CPU is so overheated it freezes.

I'm afraid I don't agree. Here is a ficticious example, which is only intended to demonstrate my point of view: If the old kernel didn't support some feature of the CPU, say L1 cache for the sake of argument, then it would run a lot slower (than a newer kernel supporting L1 cache), no matter how many programs you ran simultaneously.

BTW, I am not saying you are definitely wrong, just that it is possible you are wrong (and my guess is that you are).

say L1 cache for the sake of argument, then it would run a lot slower (than a newer kernel supporting L1 cache), no matter how many programs you ran simultaneously.

We agree there, the problem is Kernel 53.12 isn't slower at all, and thanks to better results with the Sam440SetUp file, it's also a tiny bit faster...

Maybe, as you say, some features were activated (DSP possibly?) but not in the best possible way, thus generating a lot of overhead without major benefits.
To summarize, much ado (forcing a CPU fan installation) about nothing (referred to the intangible benefits).

If they can pin point whats causing the overheat, it would be great to run some bench marks with and without the activation of such feature, just to check if it's worth the trouble and/or if the system can run as well (or better) without it.

I think you're overreacting about this topic.

ACube has managed to take the maximum of the possibilities of the 440EP (and I think not only the CPU itself but the whole board). I have overclocked my 440ep mini ITX to 733Mhz (FSB=147). It brings much heat and has to be cooled down. At 667 Mhz, no problem.

I checked the difference between Update 2 and Update 3 with some tools/games. The most noticeable speed improvement was seen with the game 1941DX Dual Player from HunoPPC.

With Update 2, the framerate was about 55 FPS, with Update 3 it's now about 73 FPS. I think it's a huge improvement in the 2D department. GfxBench 2D also shows a great increase in speed (and that what I call "a major benefit")

Regarding RageMem, there seems to be a little decrease in write memory speed (but frankly, you wouldn't notice the difference and it is largely compensated by the 2D accelaration).

Yes, overclocked Sams get hot and yes, they have to be cooled down (unless you live in a cold country ).

I will continue to use Update 3 with the Sam440 since this update brings many improvements to the little jewel from ACube and I couldn't see any speed decrease anywhere.

@K-L

I think you're overreacting about this topic.

I can assure you that I'm well over this issue and back at enjoying my system
As a passionate AmigaOS user however I just like to dig further...

ACube has managed to take the maximum of the possibilities of the 440EP (and I think not only the CPU itself but the whole board). I have overclocked my 440ep mini ITX to 733Mhz (FSB=147). It brings much heat and has to be cooled down. At 667 Mhz, no problem.

My 800Mhz system still works mighty stable no matter the load (3 emulators running simultaneously, rendering in blender with a video strugling in the back ground you name it) and with excellent speed with no extra cooling. All I need to do is to swap kernels

I checked the difference between Update 2 and Update 3 with some tools/games. The most noticeable speed improvement was seen with the game 1941DX Dual Player from HunoPPC.
With Update 2, the framerate was about 55 FPS, with Update 3 it's now about 73 FPS. I think it's a huge improvement in the 2D department. GfxBench 2D also shows a great increase in speed (and that what I call "a major benefit")

I agree.

Regarding RageMem, there seems to be a little decrease in write memory speed (but frankly, you wouldn't notice the difference and it is largely compensated by the 2D accelaration).

Not always, E-UAe sound reproduction seems to be very sensible to that change in bandwidth for example, but I guess they have time to come out with an updated Sam440SetUp later on...

Spectre660 wrote:Maybe its time to communicate with Acube outlining the problems observed .

No need. They PM'd me at AmigaWorld.net and suggested I lower the clock speed. I'm going to try that after I have tested running my system with ehci.usbhcd disabled in Kickstart. This has turned into a long topic but I have picked up a few ideas that might lead to some improvement in system stability. I'll just have to be patient enough to determine the best solution for me. Reverting to the old kernal stopped my freezes but gave me USB problems. Currently, with the ehci.usbhcd disabled I have been freeze-free for 2 days. My only problem has been a blanker failure when I left the house for a few hours with the computer on. I've had that occur rarely (once every few months) on my µA1 and SAM so I don't think it's related to my freeze problem. Who knows, I may end up operating with the old kernal, a giant CPU fan, with ehci.usbhcd disabled and CPU speed set to 667 Mhz

The one thing that nothing has fixed is muiowb. It is guaranteed to crash if I try to write a forum post. I'll work on that once I'm satisfied my system is stable enough for normal operation. RA-OWB works for me aside from a few quirks so I'm not that upset about muiowb. Eventually, they will release a new version with some of the reported problems fixed and that might work better for me.

Good to hear that Acube have communicated with you.

The muiowb issue is weird. It is rock solid here. I have update 3 installed on my Update 2 setup so it is not a clean install and the Webfonts were installed before update 3.
I have suggested that you try another graphics card if you can.
There may be an issue with update 3 and a handful of graphics cards. The symptoms for me were lockups and resets of the machine at any screen resolution over 102x768 8bit. No other tell tale sign of a problem at all.and the machine was workin with no problems up to the minutes before the update 3 install.
still need to test the card on a PC but have not had a chance.

re the screen blanker issue, I have only had the Forest and Moire modules running since update 1.
Also I cant remember if you said that you only have icons an no dockys in Amidock.

xenic wrote:

Spectre660 wrote:Maybe its time to communicate with Acube outlining the problems observed .

No need. They PM'd me at AmigaWorld.net and suggested I lower the clock speed. I'm going to try that after I have tested running my system with ehci.usbhcd disabled in Kickstart. This has turned into a long topic but I have picked up a few ideas that might lead to some improvement in system stability. I'll just have to be patient enough to determine the best solution for me. Reverting to the old kernal stopped my freezes but gave me USB problems. Currently, with the ehci.usbhcd disabled I have been freeze-free for 2 days. My only problem has been a blanker failure when I left the house for a few hours with the computer on. I've had that occur rarely (once every few months) on my µA1 and SAM so I don't think it's related to my freeze problem. Who knows, I may end up operating with the old kernal, a giant CPU fan, with ehci.usbhcd disabled and CPU speed set to 667 Mhz

The one thing that nothing has fixed is muiowb. It is guaranteed to crash if I try to write a forum post. I'll work on that once I'm satisfied my system is stable enough for normal operation. RA-OWB works for me aside from a few quirks so I'm not that upset about muiowb. Eventually, they will release a new version with some of the reported problems fixed and that might work better for me.

@Xenic
After some additional thoughts on the matter I believe we just have to give in and consider the CPUFan as the solution. The system gets hot but mixing up older and newer stuff might just hinder your experience in the end. USB2.0 doesn't work well with the older kernel, and you might also lose other advantages. Moreover what happens when the next update comes (or next Timberwolf beta which needs the new kernel?)
Just install a CPU fan and 53.22 with all its newest stuff will work ultra stable.