Should cgminer need different settings for different coins of same algorythm?

[woodrake]

Hey peeps,

I've got a weird problem. I've a rig which is quite happy mining LTC using scrypt but when I switch to FTC it dies after a few hours. I am using exactly the same settings, just different pools. My assumption has always been that what works with cgminer for one scrypt coin should work for all scrypt coins, and likewise with SHA256. In other words I should only have to tune each rig for SHA256 and scrypt, then I can point them at whatever flavour of coin I like. Is this not the case?

Kate.

[1715327685]

1715327685

[1715327685]

1715327685

[1715327685]

1715327685

[1715327685]

1715327685

[TheSpiral]

That's right, generally. Some different settings might be needed for brand new coins in Orphan City mode (like Expiry 1, Queue 0, Scantime 1), but past that point all settings should be the same. If you have -I 12 --thread-concurrency 8192 for one scrypt coin, you'll have -I 12 for --thread-concurrency for any other scrypt coin.
Only thing that changes and MIGHT cause isssues would be difficulty with the coin/pool. Nothing that should crash the card, though, just maybe have extra rejects.

[woodrake]

That's right, generally. Some different settings might be needed for brand new coins in Orphan City mode (like Expiry 1, Queue 0, Scantime 1), but past that point all settings should be the same. If you have -I 12 --thread-concurrency 8192 for one scrypt coin, you'll have -I 12 for --thread-concurrency for any other scrypt coin.
Only thing that changes and MIGHT cause isssues would be difficulty with the coin/pool. Nothing that should crash the card, though, just maybe have extra rejects.

I do run my machines quite close to their limits so perhaps it is just the additional load of small blocks / more rejects from FTC that was causing it. Also, FTC was/is being attacked so that could cause subtle differences in the workload I guess.

Anyway, thanks for confirming what I thought re. scrypt is scrypt.

Kate.