[QUOTE=storm5510;477301]My sister has one that she uses on a hardwood floor. I would not think this would be ideal for carpet.[/QUOTE]
It would indeed depend on the depth and density of the carpet pile. Such a device might get bogged down in shag.

[QUOTE=kladner;477312]It would indeed depend on the depth and density of the carpet pile. Such a device might get bogged down in shag.[/QUOTE]

Mine works well on low pile carpet and gets it very clean. It would not work well on shag.

[QUOTE=Mark Rose;477379]Mine works well on low pile carpet and gets it very clean. It would not work well on shag.[/QUOTE]

What I have is somewhere between indoor-outdoor and shag. Whoever lived here before me really loved carpet-fresh. After nearly five years, I'm still pulling that stuff out with my upright. :yucky:

Forgive me, but I'm going to go off-topic for a second: Am I right that the benchmarking bug on Xeons has not been fixed? Because I've run into that bug on build 7 as well as another benchmark bug that I don't believe has been mentioned yet. On certain worker/core tests, Prime95 will outright crash. E.g. 10 cores and 10 workers will crash; 24 cores and 22-24 workers will each crash. Crashes on different FFTs (224K, 2560K).

Dual E5-2683 v3 Xeon machine.

[QUOTE=storm5510;477454]What I have is somewhere between indoor-outdoor and shag. Whoever lived here before me really loved carpet-fresh. After nearly five years, I'm still pulling that stuff out with my upright. :yucky:[/QUOTE]
Rent a carpet cleaner. Work the carpets over: first with "heavy cleaning" dose of the prescribed detergent for the machine, then with plain water. Moving slowly gives time to really scrub and extract. Watch the returning liquid, which should be visible through some part of the machine. It should show when foam and suds have reduced.

I dealt with a similar situation in a rental beach house I was involved in. Something smelled funky, and contract cleaning crews had saturated the carpets with something which overcame the reek by sheer aggressive restroom type deodorizer. Eventually, the carpet got replaced as part of a rehab. In the meantime, we did the sort of deluge cleaning described. It took considerable fluid to flush those noxious treatments out of a very low pile commercial carpet.

We did discover the likely source of the odor being drowned out. When we tore out an island-type bar, we discovered evidence of rodent occupancy, including a desiccated rat carcass. Then, while degreasing the back of the electric stove, I found that another rat had been dining on said grease, and had crawled between the 230 V terminals.

Sorry for the digression. But seriously, wash those carpets.

[QUOTE=Jayder;477485]Forgive me, but I'm going to go off-topic for a second: Am I right that the benchmarking bug on Xeons has not been fixed? Because I've run into that bug on build 7 as well as another benchmark bug that I don't believe has been mentioned yet. On certain worker/core tests, Prime95 will outright crash. E.g. 10 cores and 10 workers will crash; 24 cores and 22-24 workers will each crash. Crashes on different FFTs (224K, 2560K).

Dual E5-2683 v3 Xeon machine.[/QUOTE]

FWIW I can run 29.4b7 on a 22-core Xeon E5 2696v4 with 22 workers on a 2560K FFT without it crashing.

[QUOTE=Jayder;477485]Forgive me, but I'm going to go off-topic for a second: Am I right that the benchmarking bug on Xeons has not been fixed? Because I've run into that bug on build 7 as well as another benchmark bug that I don't believe has been mentioned yet. On certain worker/core tests, Prime95 will outright crash. E.g. 10 cores and 10 workers will crash; 24 cores and 22-24 workers will each crash. Crashes on different FFTs (224K, 2560K).

Dual E5-2683 v3 Xeon machine.[/QUOTE]

I tried benchmarking dual Xeon E5-2690v3 in 29.4b7 and it crashed as well.

[QUOTE=LookAS;477571]I tried benchmarking dual Xeon E5-2690v3 in 29.4b7 and it crashed as well.[/QUOTE]

I'll admit, I run a lot of dual Xeons but I haven't done a benchmark run in ages.

I just started a benchmark run on a dual E5-2690v4 system... so far no crashes.

I should note that in my local.txt file I have specific worker affinity setup. I don't know if the benchmark pays attention to that like an actual worker, but perhaps the crash is coming from some core detection routine?

Here's what the relevant portion of the local.txt looks like (I have the first core in each worker be the 2nd physical one on purpose, because I think that's used for the main thread and the rest are helpers... having the main thread be something besides the first core may be helpful to prevent normal OS stuff from having the extra contention):

[CODE]WorkerThreads=2
CoresPerTest=14
NumPhysicalCores=28

[Worker #1]
Affinity=2,0,4,6,8,10,12,14,16,18,20,22,24,26

[Worker #2]
Affinity=30,28,32,34,36,38,40,42,44,46,48,50,52,54[/CODE]

With that as a guide, you can kind of figure out the numbering scheme and adjust for chips with more/less cores. Windows core numbering will alternate "physical" and hyperthread cores (i.e. the first core will be numbered 0 and 1). I think Linux does it different where all the "physical" cores are first and then come all the HT cores. So on a 4 core system, 0-3 are physical and 4-7 are hyperthread. I could be wrong on the Linux numbering, but Windows definitely works by alternating physical/HT cores.

Is it anticipated, that mprime running ECM-CF on small Mersenne numbers (M1xxx B1=2.9e9) runs only on a single thread, even though I've set the configuration to 1 worker and 4 threads?

Ah, I guess there is no ECM-CF possible for manual assignments, only ECM.

Not sure if it fits in here, but is it possible to run p-1 for a number like that: 10^75005*8-7?
How would the worktodo look like, if it works?