My Gallatin (P4 Extreme Edition, L1 8K, L2 512K, L3 2M) running hyperthreaded has completed seven results on S-40. No validations yet, but no difficulties.
As to time, all six WU's are from z1_1228.5, and S-40 CPU times are in a tight cluster around 117 minutes. As the previous S-39L times for WU's immediately preceding in sequence are tighly cluster around 125 minutes, it seem likely that S-40 is providing about an 0.94 CPU time ratio compared to S-39L on this CPU.
S-39L times 2:05 2:05 2:08 2:05 2:04 (results 1615 to 1611)
S-40 times 1:58 1:56 1:56 1:56 1:57 1:56 1:56 (results 1608 to 1602)
The calculated overall ratio for S-40 to distribution on this CPU is now 0.247.
I have just one result completed from each of my two Pentium III machines, but improvement is clear in each case.
Both are Win98SE machines. They are thus prone to report excessively high CPU times under certain disturbing circumstances (the weekly Norton scan, watching a DVD...), but I've not observed under-reporting. Thus the central tendency of the main distribution is a better comparison point than a simple average.
NetTek1:
master Datafile: z1_953.0
dominant recent S-39L CPU time: 3:38
minimum recent S-39L CPU time: 3:38:03
First S-40 CPU time: 3:30:38
Initial Estimate of S-40/S-39L CPU time .96
Cumulative dist/S-40 CPU time ratio estimate: 0.21
Dell1:
master Datafile: z1_1478.0
dominant recent S-39L CPU time: 3:04
minimum recent S-39L CPU time: 3:03:04
First S-40 CPU time: 2:56:17
Initial Estimate of S-40/S-39L CPU time .96
Cumulative dist/S-40 CPU time ratio estimate: 0.19
This latest improvement is modest compared to earlier ones, to be sure, but given that for all of my machines (one Gallatin and two Coppermines), the initial S-40 result is plumb out of the distribution of the S-39L results from nearby sequence in the same major datafile, I'll really quite confident there is an improvement for these machines. Less confident as to the specific value. My Banias machine is out of range for testing this for some days.
So, probably I found the reason of "access violation" fault. There were two chances. Software or hardware fault.
S40 is running on my five computers and I got 6 faults from 200 wus.
I got the faults one the same computer, so it gives much bigger probability to hw fault.
Right.
Quote:
But, I got the same fault. So I examined the code and the CPU more watchfully.
I found that the AGU part of the CPU cannot tolerate the higher frequencies.
I didn't have a closer look on it, but is this Duron overclocked?
Is it one of those you were once runnin @2.x GHz with watercooling?
So there is also a chance of a partial damage of the CPU.
My XP and my X2 are also OCed and I installed S40 this morning without any problems so far, but I will keep on watching.
Oh, one problem arised at the XP. In _every_ WU I get an interruption, but the results are valid. This result gives an example, while the stdoutae says:
2006-04-04 21:06:03 [Einstein@Home] Result r1_1256.5__911_S4R2a_0 exited with zero status but no 'finished' file
2006-04-04 21:06:03 [Einstein@Home] If this happens repeatedly you may need to reset the project.
But, I got the same fault. So I examined the code and the CPU more watchfully.
I found that the AGU part of the CPU cannot tolerate the higher frequencies.
I didn't have a closer look on it, but is this Duron overclocked?
Is it one of those you were once runnin @2.x GHz with watercooling?
So there is also a chance of a partial damage of the CPU.
Partial? :-)
Oh, yes. I tried out some mechanical and electrical modifications on this cpu.
A part of the body is lacking, but it is running on 2025MHz with a cheap fan.
I can't remember exactly but the maximum was under 2,4GHz with this CPU.
Quote:
Oh, one problem arised at the XP. In _every_ WU I get an interruption, but the results are valid. This result gives an example, while the stdoutae says:
2006-04-04 21:06:03 [Einstein@Home] Result r1_1256.5__911_S4R2a_0 exited with zero status but no 'finished' file
2006-04-04 21:06:03 [Einstein@Home] If this happens repeatedly you may need to reset the project.
I think this problem is between BOINC and Einstein.
I read some results of your XP. They are absolutely normal, except the heartbeat problem.
S40: I'm working on the overclocking friendly version. :-)
I didn't have a closer look on it, but is this Duron overclocked?
Is it one of those you were once runnin @2.x GHz with watercooling?
So there is also a chance of a partial damage of the CPU.
Partial? :-)
Yes! As far as I remember physics, there can be condesations of evaporated "material" from the chip when it gets really hot. These condensations change the dielectric properties of the concerned area. ;)
Quote:
Oh, yes. I tried out some mechanical and electrical modifications on this cpu.
A part of the body is lacking, but it is running on 2025MHz with a cheap fan.
I can't remember exactly but the maximum was under 2,4GHz with this CPU.
Oh, I guess you drilled a hole in the CPU to unlock the mutiplicator. ;)
When I did so the last time it also happened that a part of the body broke away. It's really hard to drill in that refractory material. (Dear kids, don't try that at home!)
Quote:
Quote:
Oh, one problem arised at the XP. In _every_ WU I get an interruption, but the results are valid. This result gives an example, while the stdoutae says:
2006-04-04 21:06:03 [Einstein@Home] Result r1_1256.5__911_S4R2a_0 exited with zero status but no 'finished' file
2006-04-04 21:06:03 [Einstein@Home] If this happens repeatedly you may need to reset the project.
I think this problem is between BOINC and Einstein.
I read some results of your XP. They are absolutely normal, except the heartbeat problem.
You mean between the client and the server?
Shouldn't my other hosts have simular problems then?
To me it looks like a communication problem between the client and albert.
I can switch back to D40 to look if the problem stays. Yesterday I upgraded my 100MBit hub to a 1GBit switch and now I use a different nic in that XP. I can also check, if that's the problem.
Quote:
S40: I'm working on the overclocking friendly version. :-)
A part of the body is lacking, but it is running on 2025MHz with a cheap fan.
I can't remember exactly but the maximum was under 2,4GHz with this CPU.
Oh, I guess you drilled a hole in the CPU to unlock the mutiplicator. ;)
When I did so the last time it also happened that a part of the body broke away. It's really hard to drill in that refractory material. (Dear kids, don't try that at home!)
Is there any relyable to hole a chip if functionality isn't a concern? A few months back one of my coworkers tried making a p4 keychain with a dead cpu. He busted a good drillbit trying to drill it and then borrowed a plasma cutter to try burning a hole. All he got for his trouble was a scorched spot on the surface.
Is there any relyable to hole a chip if functionality isn't a concern? A few months back one of my coworkers tried making a p4 keychain with a dead cpu. He busted a good drillbit trying to drill it and then borrowed a plasma cutter to try burning a hole. All he got for his trouble was a scorched spot on the surface.
You can try using a carbide drill bit. Carbide is much harder than High Speed Steel (most standard drill bits are made of HSS, and your friend probably tried this). Because carbide is much harder than HSS it is also much more brittle, which ironically makes it much easier to break. In order to keep your drill bit in one piece run it at very high rpm and maintain a very steady cutting pressure. Also don't use any coolant, I don't see why you would want to with a CPU in the way, but the coolant may also "thermally shock" the carbide causing it to break. I don't know if this is what you were asking about, but hope it helps.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
Is there any relyable to hole a chip if functionality isn't a concern? A few months back one of my coworkers tried making a p4 keychain with a dead cpu. He busted a good drillbit trying to drill it and then borrowed a plasma cutter to try burning a hole. All he got for his trouble was a scorched spot on the surface.
Long ago at a then small, now enormous semiconductor company, a colleague of mine had need to drill holes in the ceramic lid of CerDIP packages, for a hoped-for production conversion of a stock of hundreds of thousands of units. He found a method, (not only for that, but for the "secret sauce" reason for doing it). I think he used a laser--must have been a pretty energetic one--not likely one in your home shop.
On my A643200+ it seems S40
)
On my A643200+ it seems S40 is faster than D40 2%.
Wish you can understand my English:)
My Gallatin (P4 Extreme
)
My Gallatin (P4 Extreme Edition, L1 8K, L2 512K, L3 2M) running hyperthreaded has completed seven results on S-40. No validations yet, but no difficulties.
As to time, all six WU's are from z1_1228.5, and S-40 CPU times are in a tight cluster around 117 minutes. As the previous S-39L times for WU's immediately preceding in sequence are tighly cluster around 125 minutes, it seem likely that S-40 is providing about an 0.94 CPU time ratio compared to S-39L on this CPU.
S-39L times 2:05 2:05 2:08 2:05 2:04 (results 1615 to 1611)
S-40 times 1:58 1:56 1:56 1:56 1:57 1:56 1:56 (results 1608 to 1602)
The calculated overall ratio for S-40 to distribution on this CPU is now 0.247.
I'll try my Pentium IIIs next.
Hats off again, Akos. Thanks.
RE: I'll try my Pentium
)
I have just one result completed from each of my two Pentium III machines, but improvement is clear in each case.
Both are Win98SE machines. They are thus prone to report excessively high CPU times under certain disturbing circumstances (the weekly Norton scan, watching a DVD...), but I've not observed under-reporting. Thus the central tendency of the main distribution is a better comparison point than a simple average.
NetTek1:
master Datafile: z1_953.0
dominant recent S-39L CPU time: 3:38
minimum recent S-39L CPU time: 3:38:03
First S-40 CPU time: 3:30:38
Initial Estimate of S-40/S-39L CPU time .96
Cumulative dist/S-40 CPU time ratio estimate: 0.21
Dell1:
master Datafile: z1_1478.0
dominant recent S-39L CPU time: 3:04
minimum recent S-39L CPU time: 3:03:04
First S-40 CPU time: 2:56:17
Initial Estimate of S-40/S-39L CPU time .96
Cumulative dist/S-40 CPU time ratio estimate: 0.19
This latest improvement is modest compared to earlier ones, to be sure, but given that for all of my machines (one Gallatin and two Coppermines), the initial S-40 result is plumb out of the distribution of the S-39L results from nearby sequence in the same major datafile, I'll really quite confident there is an improvement for these machines. Less confident as to the specific value. My Banias machine is out of range for testing this for some days.
RE: So, probably I found
)
Right.
I didn't have a closer look on it, but is this Duron overclocked?
Is it one of those you were once runnin @2.x GHz with watercooling?
So there is also a chance of a partial damage of the CPU.
My XP and my X2 are also OCed and I installed S40 this morning without any problems so far, but I will keep on watching.
Oh, one problem arised at the XP. In _every_ WU I get an interruption, but the results are valid. This result gives an example, while the stdoutae says:
2006-04-04 21:06:03 [Einstein@Home] Result r1_1256.5__911_S4R2a_0 exited with zero status but no 'finished' file
2006-04-04 21:06:03 [Einstein@Home] If this happens repeatedly you may need to reset the project.
cu,
Michael
RE: RE: But, I got the
)
Partial? :-)
Oh, yes. I tried out some mechanical and electrical modifications on this cpu.
A part of the body is lacking, but it is running on 2025MHz with a cheap fan.
I can't remember exactly but the maximum was under 2,4GHz with this CPU.
I think this problem is between BOINC and Einstein.
I read some results of your XP. They are absolutely normal, except the heartbeat problem.
S40: I'm working on the overclocking friendly version. :-)
RE: RE: I didn't have a
)
Yes! As far as I remember physics, there can be condesations of evaporated "material" from the chip when it gets really hot. These condensations change the dielectric properties of the concerned area. ;)
Oh, I guess you drilled a hole in the CPU to unlock the mutiplicator. ;)
When I did so the last time it also happened that a part of the body broke away. It's really hard to drill in that refractory material. (Dear kids, don't try that at home!)
You mean between the client and the server?
Shouldn't my other hosts have simular problems then?
To me it looks like a communication problem between the client and albert.
I can switch back to D40 to look if the problem stays. Yesterday I upgraded my 100MBit hub to a 1GBit switch and now I use a different nic in that XP. I can also check, if that's the problem.
That's fine! :)
RE: RE: I think this
)
No...
This process doesn't change any datas.
Yes...
The only possibility.
(Heartbeat is checked between BOINC client and Einstein@Home application.)
RE: RE: A part of the
)
Is there any relyable to hole a chip if functionality isn't a concern? A few months back one of my coworkers tried making a p4 keychain with a dead cpu. He busted a good drillbit trying to drill it and then borrowed a plasma cutter to try burning a hole. All he got for his trouble was a scorched spot on the surface.
RE: Is there any relyable
)
You can try using a carbide drill bit. Carbide is much harder than High Speed Steel (most standard drill bits are made of HSS, and your friend probably tried this). Because carbide is much harder than HSS it is also much more brittle, which ironically makes it much easier to break. In order to keep your drill bit in one piece run it at very high rpm and maintain a very steady cutting pressure. Also don't use any coolant, I don't see why you would want to with a CPU in the way, but the coolant may also "thermally shock" the carbide causing it to break. I don't know if this is what you were asking about, but hope it helps.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: Is there any relyable
)
Long ago at a then small, now enormous semiconductor company, a colleague of mine had need to drill holes in the ceramic lid of CerDIP packages, for a hoped-for production conversion of a stock of hundreds of thousands of units. He found a method, (not only for that, but for the "secret sauce" reason for doing it). I think he used a laser--must have been a pretty energetic one--not likely one in your home shop.