Registered Memory (-- edit: --) is Not the Problem
 

[B]Edit:[/B] It turned out to be an issue with the current revision of CADO-NFS, rather than the first time use of Registered memory.

I recently acquired a dual Xeon machine and "tried" to put it to work with my others. It came with Registered ECC RAM. In trying to run the CADO-NFS client, the 16GB is overwhelmed. On other machines, including two Xeon dual core, the memory use is only ~4GB per client.

Could this be a result of the RAM being Registered?

In my research, I have seen references to Registered RAM running slower in some applications, but is it possible that it is causing such an increase in need?

[QUOTE=EdH;575084]I recently acquired a dual Xeon machine and "tried" to put it to work with my others. It came with Registered ECC RAM. In trying to run the CADO-NFS client, the 16GB is overwhelmed. On other machines, including two Xeon dual core, the memory use is only ~4GB per client.

Could this be a result of the RAM being Registered?

In my research, I have seen references to Registered RAM running slower in some applications, but is it possible that it is causing such an increase in need?[/QUOTE]

Probably not, but what do you mean by 'overwhelmed' ?

[QUOTE=tServo;575112]Probably not, but what do you mean by 'overwhelmed' ?[/QUOTE]
A process that takes about 4GB on all my other machines used up over 14GB of Registered memory on the "new" (to me) machine and went into swap memory. The machine was just short of seeming to be locked up. I had to issue commands via ssh and wait several minutes for them to be accepted. I removed one of the CPUs and added the two memory modules from that assembly to the single one and tried again and it acted the same.

The machine is a Z620 with Xeon e5-2630 CPU(s) AND 16GB of Registered 4x4GB modules. I tried to use some non-ECC modules as a test, but it won't work with non-ECC. I have no available ECC ATM to test with, but I do have some on the way.

Is it possible you forgot to change threads-per-client, and it spawned like 12 clients rather than 4?

[QUOTE=VBCurtis;575123]Is it possible you forgot to change threads-per-client, and it spawned like 12 clients rather than 4?[/QUOTE]
No. it's just one client, shown as "las" in "top." It's running the same script all the other machines are running and all the software is the same, other than currency. Do you think it may be the latest revision of CADO-NFS is causing it? I really think that would be stretching things. But this version is whatever it's up to as of a couple days ago.

If this is the first time you have tried your script with a different dual processor machine, I would say that is more likely the cause than the type of memory.
The link below has a nice description of how buffered memory works:
[URL="https://www.servethehome.com/unbuffered-registered-ecc-memory-difference-ecc-udimms-rdimms/"]https://www.servethehome.com/unbuffered-registered-ecc-memory-difference-ecc-udimms-rdimms/[/URL]

Also, vendors such as HP sometimes run lots of junky tasks. Are any of those consuming too much memory?

[QUOTE=tServo;575143]If this is the first time you have tried your script with a different dual processor machine, I would say that is more likely the cause than the type of memory.
The link below has a nice description of how buffered memory works:
[URL]https://www.servethehome.com/unbuffered-registered-ecc-memory-difference-ecc-udimms-rdimms/[/URL]

Also, vendors such as HP sometimes run lots of junky tasks. Are any of those consuming too much memory?[/QUOTE]I'd already found the linked page in my researh, but thank you for posting it. There shouldn't be any HP junk on this machine that isn't on the other nearly identical one.

I tried running the client with 2 threads as opposed to saturation, as the others are running (4, 8, 24) and this machine is changing its behaviour based on the threads. Two threads starts out at the ~4GB that all the others are using, but moves to ~8GB before it completes the run. A run with 4 threads, nearly immediately moves to ~10GB. I'm going to try 6 threads next and then try a regression on my CADO-NFS install and see what happens.

Thanks for all help!

Progress (or, perhaps regression)!

I updated one of my other machines to the most recemt CADO-NFS and it ran the memory up and locked up so I couldn't communicate with it in a timely fashion. Since it is headless and remote, I am now waiting fo a "pkill" command to free it, which may take a while.

At this point, I guess the CADO-NFS package is the "culprit." I'll try to verify it by changing the revision in the new machine.

[QUOTE=EdH;575157]Progress (or, perhaps regression)!

I updated one of my other machines to the most recemt CADO-NFS and it ran the memory up and locked up so I couldn't communicate with it in a timely fashion. Since it is headless and remote, I am now waiting fo a "pkill" command to free it, which may take a while.

At this point, I guess the CADO-NFS package is the "culprit." I'll try to verify it by changing the revision in the new machine.[/QUOTE]

That makes a lot more sense to me.

Otherwise, if it were to be confirmed, you would have been the first case of RAM type changing the software's memory requirements that I've ever come across in over :censored: years.

[QUOTE=PhilF;575160]That makes a lot more sense to me.

If confirmed, you would have been the first case of RAM type changing the software's memory requirements that I've ever come across in over :censored: years.[/QUOTE]
And, I consider it confirmed!

I moved the new machine back to the same revision as the others and it is running along in the manner I originally expected.

Now the dilemma of whether to report my adventure. . .

Thanks to all for help in this. I should have considered the possibility of it being CADO-NFS in the first place, but Registered memory is a new area to me and "I thought" CADO-NFS was familiar.

[QUOTE=EdH;575163]Now the dilemma of whether to report my adventure. . .[/QUOTE]

Absolutely. This sounds like a significant bug and the sooner the CADO developers find out about it, the better.