Here are my benchs : Magma Benchmark (r40Gamma3 + Ma special collections-cmm.83) (Local) : http://paste.lisp.org/display/47159 Magma Benchmark (r40Gamma3 + Ma special collections-sig.89) (Local) : http://paste.lisp.org/display/47158 I added the two text result to the mail. I will try to run the full magma test on my computer.

Florian

'Magma Benchmark (r40Gamma3 + Ma special collections-cmm.83) (Local) The date is 3 September 2007 3:42:44 pm

Hardware Details: computer : Dell Workstation PWS370 cpu : Pentium 4 speed : 3.4GHz memory : 1 Go disk : External USB2.0

OS Details: osVersion : NT platformName : Win32 platformSubtype : IX86 vmVersion : Squeak3.7 of ''4 September 2004'' [latest update: #5989] imageName : F:\Boulot\DonjOnLine\sq3.9-7067dev07.08.1base-withMagma.image

Image Details: version : Squeak3.9 lastUpdate : 7067

Code Package Details (from Monticello):

Name: Magma tester-cmm.263 Author: cmm Time: 23 August 2007, 10:33:48 pm UUID: f3d364e2-82c7-da46-800e-e3674209e452 Ancestors: Magma tester-cmm.260

Magma server details: flushAggressively : false

MagmaSession Details: isLocal : true allowWriteBarrier : false refreshPersistentObjectsEvenWhenChangedOnlyByMe : false

Benchmarker Details: thousands : 1000

Benchmarks: ---

connectionTests timeToDisconnect : 0:00:00:00.248 timeToConnect : 0:00:00:00.406 ---

readTests peakRefreshRate : 3819.192825112108 per second. singleObjectRead : 2210.757848430314 per second. oneThousandElementArrayRead : 246.6520087947232 per second. oneThousandElementArrayOfObjectsRead : 6.12285206399368 per second. oneMillionObjectPointersRead : 0.2216312056737588 per second. oneThousandLevelsDeepRead : 5.07317073170732 per second. ---

writeTests peakCommitRate : 26.66136092319936 per second. oneThousandElementArrayCommit : 19.59608078384323 per second. a1001BufferCommit : 10.91269841269841 per second. aOneMillionBufferCommit : 15 seconds. ---

magmaArrayTests getMagmaArraySize : 5471.50569886023 per second. updateThousandsOfMagmaArrayElements : 0.2248454187745925 per second. ---

magmaCollectionTests addThousandsOfObjectsTenAtATime : 7.342 seconds. addThousandsOfObjectsOneHundredAtATime : 3.883 seconds. addThousandsOfObjectsAtOnce : 3.665 seconds.'

'Magma Benchmark (r40Gamma3 + Ma special collections-sig.89) (Local) The date is 3 September 2007 3:50:18 pm

Hardware Details: computer : Dell Workstation PWS370 cpu : Pentium 4 speed : 3.4GHz memory : 1 Go disk : External USB2.0

OS Details: osVersion : NT platformName : Win32 platformSubtype : IX86 vmVersion : Squeak3.7 of ''4 September 2004'' [latest update: #5989] imageName : F:\Boulot\DonjOnLine\sq3.9-7067dev07.08.1base-withMagma.image

Image Details: version : Squeak3.9 lastUpdate : 7067

Code Package Details (from Monticello):

Name: Magma tester-cmm.263 Author: cmm Time: 23 August 2007, 10:33:48 pm UUID: f3d364e2-82c7-da46-800e-e3674209e452 Ancestors: Magma tester-cmm.260

Magma server details: flushAggressively : false

MagmaSession Details: isLocal : true allowWriteBarrier : false refreshPersistentObjectsEvenWhenChangedOnlyByMe : false

Benchmarker Details: thousands : 1000

Benchmarks: ---

connectionTests timeToDisconnect : 0:00:00:00.248 timeToConnect : 0:00:00:00.413 ---

readTests peakRefreshRate : 4218.8809914343 per second. singleObjectRead : 2463.507298540292 per second. oneThousandElementArrayRead : 267.5464907018596 per second. oneThousandElementArrayOfObjectsRead : 7.40596374975638 per second. oneMillionObjectPointersRead : 0.241721053903795 per second. oneThousandLevelsDeepRead : 6.39616230261843 per second. ---

writeTests peakCommitRate : 29.0952570745317 per second. oneThousandElementArrayCommit : 21.06099741704748 per second. a1001BufferCommit : 10.54726368159204 per second. aOneMillionBufferCommit : 13 seconds. ---

magmaArrayTests getMagmaArraySize : 5593.48130373925 per second. updateThousandsOfMagmaArrayElements : 0.2281021897810219 per second. ---

magmaCollectionTests addThousandsOfObjectsTenAtATime : 7.153 seconds. addThousandsOfObjectsOneHundredAtATime : 3.699 seconds. addThousandsOfObjectsAtOnce : 3.376 seconds.'

I tried the full tests with r40Gamma3 + Ma special collections-sig.89. Here are the problems I stepped onto.

- I wanted to run it under linux but it doesn't want to, looking for a 'squeak.exe' intead of 'squeak'. - I got a problem with firefox taking one of the listening port of the squeak image. - I got a MNU on Set>>first in TestSuite>>maExecuteTestsUsing:result:. Added two asOrderedCollection and it seemed to work. - I got a complain about the MagmaPerson and MagmaContact because it didn't found the right files. - After that the tests worked ok until i noticed the cpu down after some time and saw an Error primitiveFailed on StandardFileStream>>primSetPosition:to: on the _magmaTestServer image. Magma was trying to use an old MagmaSession from the benchmarks and couldn't open the repository. There should be some cleaning of the image before the test. Something like that : MagmaSession disconnectAndCloseAllConnectedSessions. MagmaRepositoryController initialize. MagmaServerConsole allInstances do: [:i|i shutdown]. Smalltalk garbageCollect. (btw I managed to gc all the MagmaSession with this but I don't know if it's the proper way). - I got an error EmptyStream during SecureHashAlgorithm>>hashStream: with MultiByteFileStream: 'c:\temp\Magma\objects.5.idx' as argument on the _magmaTestServer. The _testConductor image shows 'remote performing captureFileChecksumsWithCopy: with arguments #(false) in server'. The file size is 0 octet so I don't know what the hash is suppose to answer on this one. I modified the MagmaTestCase>>fileChecksums method to put 0 in the answer if the file is empty (file atEnd). Then an assertion failed when comparing the hashes of the files before and after a rollback and the only difference was that the empty file was missing. So I change that method again so if the file is empty, it's not listed in the dict. - Finally I got an assertion failed during 'remote performing verifyAddedStrings with arguments #() in client1'. The assert was on _magmaTestClient1 in MagmaTestCase>>verifyAddedStrings where 'afterImagesProgress size' equals 0. No idea what to do next.

Florian

Florian Minjat wrote:

Here are my benchs : Magma Benchmark (r40Gamma3 + Ma special collections-cmm.83) (Local) : http://paste.lisp.org/display/47159 Magma Benchmark (r40Gamma3 + Ma special collections-sig.89) (Local) : http://paste.lisp.org/display/47158 I added the two text result to the mail. I will try to run the full magma test on my computer.

Florian

Chris Muller wrote:

Hi Florian, thanks for trying the latest version. I just posted a new version, 1.0r40gamma4 which, along with the suggestions below, should address (hopefully all) of your issues.

...

• I wanted to run it under linux but it doesn't want to, looking for a

'squeak.exe' intead of 'squeak'.

I changed that to "SmalltalkImage current getSystemAttribute: 0". Does that work for you on your Linux?

I'll try later and keep you informed.

...

• I got a problem with firefox taking one of the listening port of the

squeak image.

How did you figure that out? The Magma test cases listen on 1314, 1315, 1316 and 51969. Why would Firefox be listening or connecting to one of those ports? In either case, you can set MaNetworkTestCase class>>'NextPort' to whatever value you need for your system.

No idea why, just saw it with a tcp viewer. It could be caused by a flash application. Closing Firefox solved the problem.

It sounds like you are running a special version of SUnit. At this time, Magma supports only the versions of Squeak that are listed on the Magma home page.

I was running the last squeak-dev image with updates (sq3.9-7067dev07.08.1).

...

• I got a complain about the MagmaPerson and MagmaContact because it

didn't found the right files.

They're available on the documentation page:

http://wiki.squeak.org/squeak/2661

Did you put them in your image directory?

I did put them. But the test wanted them with a different filename (MagmaContact.1.st and MagmaPerson.1.st) and kept asking them until I found it too annoying and renamed them :).

...

• After that the tests worked ok until i noticed the cpu down after

some time and saw an Error primitiveFailed on StandardFileStream>>primSetPosition:to: on the _magmaTestServer image. Magma was trying to use an old MagmaSession from the benchmarks and couldn't open the repository. There should be some cleaning of the image before the test. Something like that : MagmaSession disconnectAndCloseAllConnectedSessions. MagmaRepositoryController initialize. MagmaServerConsole allInstances do: [:i|i shutdown]. Smalltalk garbageCollect. (btw I managed to gc all the MagmaSession with this but I don't know if it's the proper way).

Hmm, that might be too presumptious for Magma to go closing down your open db's... For now, please just clean up your own databases if you don't want them open.

And is there a better or easier way to clean all that stuff ?

...

• I got an error EmptyStream during SecureHashAlgorithm>>hashStream:

with MultiByteFileStream: 'c:\temp\Magma\objects.5.idx' as argument on the _magmaTestServer. The _testConductor image shows 'remote performing captureFileChecksumsWithCopy: with arguments #(false) in server'. The file size is 0 octet so I don't know what the hash is suppose to answer on this one. I modified the MagmaTestCase>>fileChecksums method to put 0 in the answer if the file is empty (file atEnd).

Please expect the tests to run from start to finish without any problems. If they don't, there's a problem and what you are doing is simply trying to hide a problem with the test that shouldn't have occurred in the first place. When you have as many problems as you had getting this far, it's very likely this was caused by a previous problem. You should focus on getting a clean run before trying to "fix" potential non-problems.

I never proceed a failed test. Each problem I mentionned was the only one of a test run. The problem with the empty files was a real problem and occured each time.

...

Then an assertion failed when comparing the hashes of the files before and after a rollback and the only difference was that the empty file was missing. So I change that method again so if the file is empty, it's not listed in the dict.

Not a good change because it shouldn't happen. If it does we need to investigate why, not simply hide it.

...

• Finally I got an assertion failed during 'remote performing

verifyAddedStrings with arguments #() in client1'. The assert was on _magmaTestClient1 in MagmaTestCase>>verifyAddedStrings where 'afterImagesProgress size' equals 0. No idea what to do next.

It sounds like your earlier failures led to later failures. The test cases should run from start to finish without interruption.

The only thing that could have led to this problem was the empty file whose fix was to simply ignore it. The test run was launched from the start without errors.

I will try your new version today to see if I got any other errors.

Thanks for our answer !

Florian

• Chris

...

Florian Minjat wrote:

...

Here are my benchs : Magma Benchmark (r40Gamma3 + Ma special collections-cmm.83) (Local) : http://paste.lisp.org/display/47159 Magma Benchmark (r40Gamma3 + Ma special collections-sig.89) (Local) : http://paste.lisp.org/display/47158 I added the two text result to the mail. I will try to run the full magma test on my computer.

Florian

---

Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma

Hi Florian, I had some time to explore this on my Linux machine. Although I was not able to reproduce the empty file problem, running the test cases through did snag very strangely the first couple of times; in different places!

In both cases, the whatever failure occurred was immediately invisible. For example, the first case was in MagmaCollectionTester>>#verifyOrder:against:. In there we have:

self assert: aMagmaCollectionReader size = aSortedCollection size.

which failed but when I immediately printed the sizes, they matched! I restarted that method, proceed the debugger and the tests finished through to completion.

Not satisfied, I ran them again. This time it failed in a similar way; the debugger appeared during a restore test because MaRecoveryRecord>>#hasValidCheckSum answered false. Upon immediately comparing "self calculatedCheckSum = self checkSum" they were equal! So I once again proceeded the test and they all ran through to completion.

In each case there was just the one failure and, in each case, my common "hunch" was something like: "Maybe with Linux a separate readStream (different file-handle) only gets the physical (unflushed) contents of the file. This reminded me that #flushAggressively is set to false by default. It really should be true but I was always afraid of poor performance.

Well, it doesn't hurt performance that much, taking my peak commit rate on that (slow) laptop from 19.9 per second to 19.8 per second. And, alas, by defaulting it to true all the test cases ran through, start to finish, without a single interruption on Linux.

So I've posted this update as r40gamma6 on Magma Tester. Please give it a try. Also, make sure you have some of those recent fixes from Andreas; the Delay and Semaphore fixes. I don't know whether they make a difference for what you're experiencing, but they could, and I have them and didn't experience what you did.

Thanks, Chris

On 9/10/07, Florian Minjat florian.minjat@emn.fr wrote:

Chris Muller wrote:

...

Hi Florian, thanks for trying the latest version. I just posted a new version, 1.0r40gamma4 which, along with the suggestions below, should address (hopefully all) of your issues.

...

• I wanted to run it under linux but it doesn't want to, looking for a

'squeak.exe' intead of 'squeak'.

I changed that to "SmalltalkImage current getSystemAttribute: 0". Does that work for you on your Linux?

No it didn't. I used this in MaNetworkTestCase class>>launchImageNamed: "(Smalltalk classNamed: #OSProcess) command: self executableName, ' ' , (SmalltalkImage current imagePath), FileDirectory slash , imageName"

And in MaNetworkTestCase class>>executableName : "OSProcess programName" It should be platform independent but I can't test under windows until tomorrow.

...

...

• I got an error EmptyStream during SecureHashAlgorithm>>hashStream:

with MultiByteFileStream: 'c:\temp\Magma\objects.5.idx' as argument on the _magmaTestServer. The _testConductor image shows 'remote performing captureFileChecksumsWithCopy: with arguments #(false) in server'. The file size is 0 octet so I don't know what the hash is suppose to answer on this one. I modified the MagmaTestCase>>fileChecksums method to put 0 in the answer if the file is empty (file atEnd).

Please expect the tests to run from start to finish without any problems. If they don't, there's a problem and what you are doing is simply trying to hide a problem with the test that shouldn't have occurred in the first place. When you have as many problems as you had getting this far, it's very likely this was caused by a previous problem. You should focus on getting a clean run before trying to "fix" potential non-problems.

Same error on the same empty file. And the test was fine from the start.

Florian _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma