OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 703.

jjiimm_64

legendary

Activity: 1876

Merit: 1000

Quote from: padrino on January 15, 2012, 02:31:08 PM

Has any successfully used gpu-vddc on Radeon 5970 cards? The GPU results when looking at details are providing the correct results at 1.050 but if I change the voltage to something else it still reports the stock voltage. I'm running 8 GPUs (4x5970) so I am using Linux due to stability issues in Windows so I cannot use MSI Afterburner or similar Windows tools.

I just tried to change the voltage, but when I add the voltage line to the conf file, the program reports an error parsing json conf file.
"gpu-vddc" : "1.05",

padrino

legendary

Activity: 1428

Merit: 1000

https://www.bitworks.io

Has any successfully used gpu-vddc on Radeon 5970 cards? The GPU results when looking at details are providing the correct results at 1.050 but if I change the voltage to something else it still reports the stock voltage. I'm running 8 GPUs (4x5970) so I am using Linux due to stability issues in Windows so I cannot use MSI Afterburner or similar Windows tools.

P4man

hero member

Activity: 518

Merit: 500

ONe of my rigs was getting slower than usual hashrates; I noticed utilization was at 0%. A reboot solved the hashrate, but I went in to dmesg and found something slightly worrying. Can anyone make sense of this?

Code:

[  141.231341] debug_smp_processor_id: 1080 callbacks suppressed
[  141.231345] BUG: using smp_processor_id() in preemptible [00000000] code: cgminer/4772
[  141.231351] Pid: 4772, comm: cgminer Tainted: P         C O 2.6.39-3-amd64 #1
[  141.231354] Call Trace:
[  141.231367]  [] ? debug_smp_processor_id+0xb2/0xc8
[  141.231446]  [] ? kas_spin_lock+0x15/0xbd [fglrx]
[  141.231472]  [] ? KAS_InterlockedList_RemoveAtHead+0x58/0x152 [fglrx]
[  141.231505]  [] ? MCIL_InterlockedList+0x10d/0x2a0 [fglrx]
[  141.231557]  [] ? FIFO_Queue_RemoveFromHead+0x40/0x60 [fglrx]
[  141.231591]  [] ? MCIL_bMiniportCapEnabled+0x82/0xa0 [fglrx]
[  141.231634]  [] ? AllocateCallbackEntry+0x21/0x50 [fglrx]
[  141.231681]  [] ? RegisterIRQClient+0x7a/0x1c0 [fglrx]
[  141.231723]  [] ? Is_IRQSource_Valid+0x8e/0xb0 [fglrx]
[  141.231771]  [] ? IRQMGR_Access+0xee/0x190 [fglrx]
[  141.231803]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.231835]  [] ? IRQMGR_enable_hifreq_interrupt+0xee/0x150 [fglrx]
[  141.231871]  [] ? firegl_trace+0x72/0x1e0 [fglrx]
[  141.231903]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.231936]  [] ? irqmgr_wrap_enable_hifreq_interrupt+0x5c/0x1f0 [fglrx]
[  141.231967]  [] ? MCIL_KernelMutex+0x134/0x320 [fglrx]
[  141.231993]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0xe23a/0xb05d1 [fglrx]
[  141.232006]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.232072]  [] ? firegl_cmmqs_QueryThreadWakeupSource+0xab/0xd0 [fglrx]
[  141.232106]  [] ? MCIL_SuspendThread+0x106/0x120 [fglrx]
[  141.232131]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.232188]  [] ? _ZN2OS13suspendThreadEj+0x22/0x30 [fglrx]
[  141.232243]  [] ? CMMQSWaitOnTsSignal+0xaa/0xd0 [fglrx]
[  141.232300]  [] ? _Z8uCWDDEQCmjjPvjS_+0xc32/0x10c0 [fglrx]
[  141.232338]  [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
[  141.232374]  [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
[  141.232399]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1370/0xb05d1 [fglrx]
[  141.232436]  [] ? firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
[  141.232467]  [] ? firegl_ioctl+0x1e8/0x250 [fglrx]
[  141.232495]  [] ? ip_firegl_unlocked_ioctl+0x9/0xd [fglrx]
[  141.232502]  [] ? do_vfs_ioctl+0x50e/0x564
[  141.232506]  [] ? sys_ioctl+0x4b/0x6f
[  141.232515]  [] ? system_call_fastpath+0x16/0x1b
[  141.232519]  [] ? sysret_check+0x24/0x5f
[  141.232932] BUG: using smp_processor_id() in preemptible [00000000] code: cgminer/4772
[  141.232936] Pid: 4772, comm: cgminer Tainted: P         C O 2.6.39-3-amd64 #1
[  141.232938] Call Trace:
[  141.232945]  [] ? debug_smp_processor_id+0xb2/0xc8
[  141.232971]  [] ? KAS_GetExecutionLevel+0xd/0x1d [fglrx]
[  141.233003]  [] ? MCIL_GetExecutionLevel+0x39/0x80 [fglrx]
[  141.233053]  [] ? CallbackQueueAccess+0x2b/0x2a0 [fglrx]
[  141.233098]  [] ? IRQMGR_QueryAsicTimestamp+0x20/0x20 [fglrx]
[  141.233144]  [] ? RegisterIRQClient+0xdb/0x1c0 [fglrx]
[  141.233190]  [] ? IRQMGR_Access+0xee/0x190 [fglrx]
[  141.233222]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.233254]  [] ? IRQMGR_enable_hifreq_interrupt+0xee/0x150 [fglrx]
[  141.233288]  [] ? firegl_trace+0x72/0x1e0 [fglrx]
[  141.233319]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.233351]  [] ? irqmgr_wrap_enable_hifreq_interrupt+0x5c/0x1f0 [fglrx]
[  141.233382]  [] ? MCIL_KernelMutex+0x134/0x320 [fglrx]
[  141.233405]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0xe23a/0xb05d1 [fglrx]
[  141.233429]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.233464]  [] ? firegl_cmmqs_QueryThreadWakeupSource+0xab/0xd0 [fglrx]
[  141.233495]  [] ? MCIL_SuspendThread+0x106/0x120 [fglrx]
[  141.233518]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.233571]  [] ? _ZN2OS13suspendThreadEj+0x22/0x30 [fglrx]
[  141.233621]  [] ? CMMQSWaitOnTsSignal+0xaa/0xd0 [fglrx]
[  141.233674]  [] ? _Z8uCWDDEQCmjjPvjS_+0xc32/0x10c0 [fglrx]
[  141.233709]  [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
[  141.233744]  [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
[  141.233767]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1370/0xb05d1 [fglrx]
[  141.233802]  [] ? firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
[  141.233830]  [] ? firegl_ioctl+0x1e8/0x250 [fglrx]
[  141.233855]  [] ? ip_firegl_unlocked_ioctl+0x9/0xd [fglrx]
[  141.233859]  [] ? do_vfs_ioctl+0x50e/0x564
[  141.233863]  [] ? sys_ioctl+0x4b/0x6f
[  141.233867]  [] ? system_call_fastpath+0x16/0x1b
[  141.233870]  [] ? sysret_check+0x24/0x5f
[  141.233874] BUG: using smp_processor_id() in preemptible [00000000] code: cgminer/4772
[  141.233878] Pid: 4772, comm: cgminer Tainted: P         C O 2.6.39-3-amd64 #1
[  141.233879] Call Trace:
[  141.233883]  [] ? debug_smp_processor_id+0xb2/0xc8
[  141.233928]  [] ? IRQMGR_QueryAsicTimestamp+0x20/0x20 [fglrx]
[  141.233952]  [] ? KAS_GetExecutionLevel+0xd/0x1d [fglrx]
[  141.233983]  [] ? MCIL_GetExecutionLevel+0x39/0x80 [fglrx]
[  141.234009]  [] ? MCIL_QuerySystemInfo+0xb2/0x100 [fglrx]
[  141.234061]  [] ? IRQMGR_SynchronizeExecution+0x25/0x80 [fglrx]
[  141.234101]  [] ? IRQMGR_GetCurrentThreadId+0x38/0x50 [fglrx]
[  141.234143]  [] ? CallbackQueueAccess+0x164/0x2a0 [fglrx]
[  141.234188]  [] ? IRQMGR_QueryAsicTimestamp+0x20/0x20 [fglrx]
[  141.234233]  [] ? RegisterIRQClient+0xdb/0x1c0 [fglrx]
[  141.234279]  [] ? IRQMGR_Access+0xee/0x190 [fglrx]
[  141.234311]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.234342]  [] ? IRQMGR_enable_hifreq_interrupt+0xee/0x150 [fglrx]
[  141.234377]  [] ? firegl_trace+0x72/0x1e0 [fglrx]
[  141.234408]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.234440]  [] ? irqmgr_wrap_enable_hifreq_interrupt+0x5c/0x1f0 [fglrx]
[  141.234470]  [] ? MCIL_KernelMutex+0x134/0x320 [fglrx]
[  141.234494]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0xe23a/0xb05d1 [fglrx]
[  141.234517]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.234552]  [] ? firegl_cmmqs_QueryThreadWakeupSource+0xab/0xd0 [fglrx]
[  141.234583]  [] ? MCIL_SuspendThread+0x106/0x120 [fglrx]
[  141.234606]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.234659]  [] ? _ZN2OS13suspendThreadEj+0x22/0x30 [fglrx]
[  141.234709]  [] ? CMMQSWaitOnTsSignal+0xaa/0xd0 [fglrx]
[  141.234762]  [] ? _Z8uCWDDEQCmjjPvjS_+0xc32/0x10c0 [fglrx]
[  141.234797]  [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
[  141.234832]  [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
[  141.234855]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1370/0xb05d1 [fglrx]
[  141.234890]  [] ? firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
[  141.234918]  [] ? firegl_ioctl+0x1e8/0x250 [fglrx]
[  141.234943]  [] ? ip_firegl_unlocked_ioctl+0x9/0xd [fglrx]
[  141.234947]  [] ? do_vfs_ioctl+0x50e/0x564
[  141.234951]  [] ? sys_ioctl+0x4b/0x6f
[  141.234955]  [] ? system_call_fastpath+0x16/0x1b
[  141.234958]  [] ? sysret_check+0x24/0x5f
[  141.909206] BUG: using smp_processor_id() in preemptible [00000000] code: cgminer/4776
[  141.909212] Pid: 4776, comm: cgminer Tainted: P         C O 2.6.39-3-amd64 #1
[  141.909215] Call Trace:
[  141.909226]  [] ? debug_smp_processor_id+0xb2/0xc8
[  141.909274]  [] ? kas_spin_lock+0x15/0xbd [fglrx]
[  141.909299]  [] ? KAS_InterlockedList_RemoveAtHead+0x58/0x152 [fglrx]
[  141.909331]  [] ? MCIL_InterlockedList+0x10d/0x2a0 [fglrx]
[  141.909379]  [] ? FIFO_Queue_RemoveFromHead+0x40/0x60 [fglrx]
[  141.909403]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0xff3c/0xb05d1 [fglrx]
[  141.909436]  [] ? MCIL_bMiniportCapEnabled+0x82/0xa0 [fglrx]
[  141.909478]  [] ? AllocateCallbackEntry+0x21/0x50 [fglrx]
[  141.909524]  [] ? RegisterIRQClient+0x7a/0x1c0 [fglrx]
[  141.909565]  [] ? Is_IRQSource_Valid+0x8e/0xb0 [fglrx]
[  141.909612]  [] ? IRQMGR_Access+0xee/0x190 [fglrx]
[  141.909644]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.909676]  [] ? IRQMGR_enable_hifreq_interrupt+0xee/0x150 [fglrx]
[  141.909711]  [] ? firegl_trace+0x72/0x1e0 [fglrx]
[  141.909743]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.909776]  [] ? irqmgr_wrap_enable_hifreq_interrupt+0x5c/0x1f0 [fglrx]
[  141.909807]  [] ? MCIL_KernelMutex+0x134/0x320 [fglrx]
[  141.909831]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.909867]  [] ? firegl_cmmqs_QueryThreadWakeupSource+0xab/0xd0 [fglrx]
[  141.909898]  [] ? MCIL_SuspendThread+0x106/0x120 [fglrx]
[  141.909922]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.909976]  [] ? _ZN2OS13suspendThreadEj+0x22/0x30 [fglrx]
[  141.910003]  [] ? CMMQSWaitOnTsSignal+0xaa/0xd0 [fglrx]
[  141.910094]  [] ? _Z8uCWDDEQCmjjPvjS_+0xc32/0x10c0 [fglrx]
[  141.910131]  [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
[  141.910168]  [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
[  141.910193]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1370/0xb05d1 [fglrx]
[  141.910230]  [] ? firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
[  141.910261]  [] ? firegl_ioctl+0x1e8/0x250 [fglrx]
[  141.910288]  [] ? ip_firegl_unlocked_ioctl+0x9/0xd [fglrx]
[  141.910295]  [] ? do_vfs_ioctl+0x50e/0x564
[  141.910301]  [] ? sys_ioctl+0x4b/0x6f
[  141.910308]  [] ? system_call_fastpath+0x16/0x1b
[  141.910314] BUG: using smp_processor_id() in preemptible [00000000] code: cgminer/4776
[  141.910320] Pid: 4776, comm: cgminer Tainted: P         C O 2.6.39-3-amd64 #1
[  141.910323] Call Trace:
[  141.910328]  [] ? debug_smp_processor_id+0xb2/0xc8
[  141.910354]  [] ? KAS_GetExecutionLevel+0xd/0x1d [fglrx]
[  141.910387]  [] ? MCIL_GetExecutionLevel+0x39/0x80 [fglrx]
[  141.910431]  [] ? CallbackQueueAccess+0x2b/0x2a0 [fglrx]
[  141.910478]  [] ? IRQMGR_QueryAsicTimestamp+0x20/0x20 [fglrx]
[  141.910525]  [] ? RegisterIRQClient+0xdb/0x1c0 [fglrx]
[  141.910573]  [] ? IRQMGR_Access+0xee/0x190 [fglrx]
[  141.910607]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.910640]  [] ? IRQMGR_enable_hifreq_interrupt+0xee/0x150 [fglrx]
[  141.910676]  [] ? firegl_trace+0x72/0x1e0 [fglrx]
[  141.910710]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.910744]  [] ? irqmgr_wrap_enable_hifreq_interrupt+0x5c/0x1f0 [fglrx]
[  141.910776]  [] ? MCIL_KernelMutex+0x134/0x320 [fglrx]
[  141.910802]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.910839]  [] ? firegl_cmmqs_QueryThreadWakeupSource+0xab/0xd0 [fglrx]
[  141.910872]  [] ? MCIL_SuspendThread+0x106/0x120 [fglrx]
[  141.910897]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.910952]  [] ? _ZN2OS13suspendThreadEj+0x22/0x30 [fglrx]
[  141.911004]  [] ? CMMQSWaitOnTsSignal+0xaa/0xd0 [fglrx]
[  141.911062]  [] ? _Z8uCWDDEQCmjjPvjS_+0xc32/0x10c0 [fglrx]
[  141.911099]  [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
[  141.911136]  [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
[  141.911161]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1370/0xb05d1 [fglrx]
[  141.911198]  [] ? firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
[  141.911228]  [] ? firegl_ioctl+0x1e8/0x250 [fglrx]
[  141.911255]  [] ? ip_firegl_unlocked_ioctl+0x9/0xd [fglrx]
[  141.911261]  [] ? do_vfs_ioctl+0x50e/0x564
[  141.911266]  [] ? sys_ioctl+0x4b/0x6f
[  141.911272]  [] ? system_call_fastpath+0x16/0x1b
[  141.911277] BUG: using smp_processor_id() in preemptible [00000000] code: cgminer/4776
[  141.911282] Pid: 4776, comm: cgminer Tainted: P         C O 2.6.39-3-amd64 #1
[  141.911286] Call Trace:
[  141.911291]  [] ? debug_smp_processor_id+0xb2/0xc8
[  141.911338]  [] ? IRQMGR_QueryAsicTimestamp+0x20/0x20 [fglrx]
[  141.911363]  [] ? KAS_GetExecutionLevel+0xd/0x1d [fglrx]
[  141.911396]  [] ? MCIL_GetExecutionLevel+0x39/0x80 [fglrx]
[  141.911429]  [] ? MCIL_QuerySystemInfo+0xb2/0x100 [fglrx]
[  141.911472]  [] ? IRQMGR_SynchronizeExecution+0x25/0x80 [fglrx]
[  141.911514]  [] ? IRQMGR_GetCurrentThreadId+0x38/0x50 [fglrx]
[  141.911558]  [] ? CallbackQueueAccess+0x164/0x2a0 [fglrx]
[  141.911605]  [] ? IRQMGR_QueryAsicTimestamp+0x20/0x20 [fglrx]
[  141.911652]  [] ? RegisterIRQClient+0xdb/0x1c0 [fglrx]
[  141.911700]  [] ? IRQMGR_Access+0xee/0x190 [fglrx]
[  141.911733]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.911767]  [] ? IRQMGR_enable_hifreq_interrupt+0xee/0x150 [fglrx]
[  141.911803]  [] ? firegl_trace+0x72/0x1e0 [fglrx]
[  141.911836]  [] ? irqmgr_interrupt_handler+0x20/0x20 [fglrx]
[  141.911870]  [] ? irqmgr_wrap_enable_hifreq_interrupt+0x5c/0x1f0 [fglrx]
[  141.911903]  [] ? MCIL_KernelMutex+0x134/0x320 [fglrx]
[  141.911928]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.911966]  [] ? firegl_cmmqs_QueryThreadWakeupSource+0xab/0xd0 [fglrx]
[  141.911999]  [] ? MCIL_SuspendThread+0x106/0x120 [fglrx]
[  141.912026]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1f650/0xb05d1 [fglrx]
[  141.912079]  [] ? _ZN2OS13suspendThreadEj+0x22/0x30 [fglrx]
[  141.912130]  [] ? CMMQSWaitOnTsSignal+0xaa/0xd0 [fglrx]
[  141.912183]  [] ? _Z8uCWDDEQCmjjPvjS_+0xc32/0x10c0 [fglrx]
[  141.912219]  [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
[  141.912254]  [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
[  141.912278]  [] ? _ZThn808_N8GartPppt14CreateApertureEv+0x1370/0xb05d1 [fglrx]
[  141.912313]  [] ? firegl_cmmqs_createdriver+0x170/0x170 [fglrx]
[  141.912342]  [] ? firegl_ioctl+0x1e8/0x250 [fglrx]
[  141.912367]  [] ? ip_firegl_unlocked_ioctl+0x9/0xd [fglrx]
[  141.912372]  [] ? do_vfs_ioctl+0x50e/0x564
[  141.912376]  [] ? sys_ioctl+0x4b/0x6f
[  141.912380]  [] ? system_call_fastpath+0x16/0x1b

jake262144

full member

Activity: 210

Merit: 100

Yeah, BFL earned every bit of the backlash they're receiving

I'm slightly disappointed at your not being able to find the availability schedule, for it has been the most stable part of the whole enterprise for the last 2 months. It's - invariably - 4 to 6 weeks.

This is my last OT joke here. Please don't hold it against me con, I just couldn't help myself - BFL are practically begging to be ridiculed. I'll donate yet again if that will buy me your absolution Grin

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jake262144 on January 15, 2012, 07:11:59 AM

I suppose that's because unlike every other device, the BFL product is a fully professional design, built by engineers with no less than 10 years of experience under their belt.

I would also like to point out, if I may be so bold, that unlike the typical chinese ~~sweatshops~~^Wfactories hastily putting together your generic USB devices en-masse, BFL (sadly no longer Inc.) have been concentrating all their efforts exclusively on the BitForce FPGA miner for the whole last quarter. Without a doubt, their corporate motto is "slowly but surely".

Try reading the BFL thread, Kano, it has all the answers Grin

Unfortunately I did read one of the BFL threads and it was a nightmare of claims, counter claims, abuse and generally a large amount of total crap for 41 pages (took me a few hours ...) that I searched for details about the device and it's performance and when it would be available ...

jake262144

full member

Activity: 210

Merit: 100

I suppose that's because unlike every other device, the BFL product is a fully professional design, built by engineers with no less than 10 years of experience under their belt.

I would also like to point out, if I may be so bold, that unlike the typical chinese ~~sweatshops~~^Wfactories hastily putting together your generic USB devices en-masse, BFL (sadly no longer Inc.) have been concentrating all their efforts exclusively on the BitForce FPGA miner for the whole last quarter. Without a doubt, their corporate motto is "slowly but surely".

Try reading the BFL thread, Kano, it has all the answers Grin

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

I will also add that the detection explanation seems extremely strange.
Whenever you plug a USB device into a linux system you see messages in dmesg about the identity of the device.
That information (however you get access to it) should be enough to know what it is shouldn't it?
Or are they not handling the USB connection with identity information like every other USB device on the planet I've plugged into a linux box?

jake262144

full member

Activity: 210

Merit: 100

Quote from: -ck on January 15, 2012, 04:45:48 AM

... Even well coded around, it's still an inefficient means of communicating and I'm disappointed to see it in a new device in this day and age.

Well said, con.

*chanting* BFL toaster, BFL toaster, BFL toaster...
Grin

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Nonetheless, most interfaces that need polling lead to significant busy-waiting loops in the code to make sure they don't miss an opportunity to give out more work. This is *exactly* the sort of shit that led to high CPU usage in many iterations of the ATI driver. Now I haven't looked at that part of Luke-jr's code to see how he manages it, but you can minimise the effect somewhat by not simply polling indefinitely, and he has said he went to some effort to work around it. Even well coded around, it's still an inefficient means of communicating and I'm disappointed to see it in a new device in this day and age.

P4man

hero member

Activity: 518

Merit: 500

ms? No way. To give you an idea, USB2.0 has a latency of ~100 ~~picoseconds~~ nanoseconds.
That is 0.000 000 1 seconds or 0.0001 ms.
If the latency is anywhere within a few orders of magnitude of a full ms, than it has nothing to do with USB.

Not saying its an elegant solution, but its not likely to cause any trouble either IMO.

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

If the FPGA has a micro controller attached then the smart way to do this would be to have a job queued ready for it to start new work as soon as finished. The micro controller should store the next job. Then the polling could be much reduced.

Also, as far as I know the USB interface will buffer data so the miner could just send finished work data and the PC just has to check it's buffer for finished work, and issue a new job. Or the PC could be set to interrupt on USB data ready.

A 10mS polling time isn't terrible but the more units hanging off USB cables the more work required to poll many of them. I don't know where the limit is but it's a lot of work for nothing. If a poll takes 1mS then you'd be limited to 10 units. I suspect it may be faster but maybe not, given it has to go thru all the USB protocol stuff, talk to the FPGA and get back a result. With so much wonderful tech in play it seems like a butchers approach to queuing work.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jake262144 on January 14, 2012, 08:09:43 PM

Quote from: rjk on January 14, 2012, 07:39:44 PM

Is it not easily possible to modify the firmware to push a result back, instead of needing to be polled continuously?

THAT. Busy-waiting is a horribly inelegant approach.

Hmm I wonder how that response protocol compares to the ATI card procedure.
(I have no idea and have never delved closely into that part of the code)
But it does seem rather surprising for the design to have a possibility that the device can be idle for an entire busy-wait period ...
So on average it will be idle for half the busy-wait period per work request.

jake262144

full member

Activity: 210

Merit: 100

Quote from: rjk on January 14, 2012, 07:39:44 PM

Is it not easily possible to modify the firmware to push a result back, instead of needing to be polled continuously?

THAT. Busy-waiting is a horribly inelegant approach.

rjk

sr. member

Activity: 448

Merit: 250

1ngldh

Quote from: BFL on January 14, 2012, 07:05:09 PM

After the sent job, driver must keep asking the device for status (10ms is preferred polling interval).

Is it not easily possible to modify the firmware to push a result back, instead of needing to be polled continuously?

BFL

full member

Activity: 217

Merit: 100

Hi guys, please excuse the intrusion...

I know many of our customers use CGMiner and that there has been some work on your code base to support our units. In furtherance of that effort, I thought you might like to have our protocol spec for communicating with BitForce devices.

Please let me know if you have any questions or if you need remote access to a unit for code testing.

Kind Regards,
BFL

BitForce communication protocol:

1) Detection
-----------------------------------
BitFORCE on linux will be recognized as a ttyUSB device in /dev/ folder (i.e. ttyUSB0 or ttyUSB1, etc).
In order to find our device, one must test all the ttyUSB devices found in /dev/ folder, open them
and send them the ID request command (string: 'ZAX'). After the command is sent, if a response is
received (will resemble '>>>ID: BitFORCE SHA256 Version X.Y>>>'), then a BitFORCE device has been
detected. (X and Y represent a numerical version)

On windows, one must perform the same on all COM and VCOM devices (COM1, COM2, etc...).

2) Information
----------------------------------
Once a device is detected, an information request command 'ZGX' can be sent to the device.
BitFORCE will respond by sending detailed data regarding its firmware version, hash and so on.
Please note that no carriage-return must be appended to the end of any command identifiers.

2) Sending a job request
----------------------------------
To send a bitcoin job request, first the command ID must be sent (string: 'ZDX'). The device will respond
with an 'OK' (followed by a carriage return). At this point, device is ready to accept a Bitcoin job. (Note: If 'BUSY' was returned, it means either the device is not intialized yet, or is processing another job)

Next is to send a bitcoin job. A job-packet must have the following format:

   1) Starts with '>>>>>>>>'
   2) Following is 256bits of MIDSTATE
   3) Next is our last 12 bytes of block-header (Block header is 86 Bytes, the last 12 is needed here)
   4) Packet ends with '>>>>>>>>'

Please note that the byte-ordering is identical to what is received on JSON data. No conversion is therefore needed.

Once this is done, the device will send back an 'OK' (followed by carriage return). System starts
processing the bitcoin hash from this point.

3) Checking for results
-------------------------------
After the sent job, driver must keep asking the device for status (10ms is preferred polling interval).
Status command is 'ZFX'. Once sent, the unit may respond with one of the predefined responses:

   * BUSY
   (Device is busy processing a block. You can still issue a job, but the previous process will be
   discarded and new process will start)

   * IDLE
   (Device is not processing anything)

   * NONCE-FOUND:<8 Hexadecimal characters defining the found Nonce>, <8 Hexa decimal of the second found nonce>...
   Note: The last nonce will not be terminated by a comma. The byte-ordering is Little-Endian
   Example: NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB (3 valid nonces are discovered in this process)

   * NO-NONCE
   Processing has been finished, no valid nonce was detected.

Note that all responses from BitFORCE units are followed by a carriage-return.

End...

jjiimm_64

legendary

Activity: 1876

Merit: 1000

Quote from: jjiimm_64 on January 13, 2012, 11:22:09 PM

Quote from: kano on January 13, 2012, 06:29:20 PM

But yeah - state exactly what you want with those 2 commands and once the CPU changes happen I'll put those 2 on first priority (for 5 BTC

quote myself...

Quote

Kano,
  What I am looking for is basically exactly what you would do if you went thru the apps interface to:

1. switch pool
   P -> S -> pool number

2. change engine clock
   G -> C -> GPU# -> E -> newValue

3. change mem clock
   G -> C -> GPU# -> M -> newValue

I guess just about any one of the gpu changes would be good, but the 3 above I think are critical. Even if you can control the fan (I usually have on auto) you can always lower the Eclock down to try and kool it.. or disable the card which you have already implimented.

I would like to revise the above list with this one.

1. ability to switch pools (i think setting a pools priority to 0 would work?)
2. setting any of the following, for 1 or all gpus's:

"intensity" : "newValue",
"gpu-engine" : "newValue",
"gpu-memclock" : "newValue",
"gpu-fan": "newValue", ex(50-85)

I realize the 'all gpus' could get tricky, because most of these takes possible a comma delim list. and i have no idea how it is implimented so just one at a time is good

also just wanted to bump this up again. i know we are waiting to resolve the code/trunk issues.

here is a sample of the single php page summary of all cgminers in farm no database needed..
http://cgminerweb.com/example.miner.php.html (html snapshot)

I ment to write new post but apparently edited the old one... bump

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: kano on January 14, 2012, 04:32:40 PM

Actually this issue has been discussed quite a few times.
The last time recently was:
https://bitcointalksearch.org/topic/m.671582

I guess if ckolivas doesn't put it in, I'll add an FAQ about the bin files when I do my next changes - hopefully soon

(and explain it a bit more as stated this time)
Though, apparently almost no one reads the FAQ in the README file Cheesy

Yeah I even tried explaining but I didn't spell it out, so even if I put it into the readme, it would have been "too hard dunno wtf you're talking about" or wouldn't have been read.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Actually this issue has been discussed quite a few times.
The last time recently was:
https://bitcointalksearch.org/topic/m.671582

I guess if ckolivas doesn't put it in, I'll add an FAQ about the bin files when I do my next changes - hopefully soon

(and explain it a bit more as stated this time)
Though, apparently almost no one reads the FAQ in the README file Cheesy

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: jjiimm_64 on January 14, 2012, 02:48:27 PM

Quote from: Fiyasko on January 14, 2012, 04:02:33 AM

Quote from: jjiimm_64 on January 14, 2012, 03:25:41 AM

Quote from: Fiyasko on January 14, 2012, 03:15:49 AM

Lets get the obvious questions out of the way
Could your drivers have updated recently?
Your Obviously talking about the newer version of CGminer right? If not, SDK2.6 is your problem.

yes, i updated the ccc a month ago to get rid of the 100% bug. i have 11-12_vista64_win7_64_dd_ccc_ocl.exe

if I run the older version of cgminer, i get the normal hashrates. This did not affect the other 14 rigs running linuxcoin

Who wants to jump in, Thats fucked

then, after DAT 'jumped in'.

Quote from: Fiyasko on January 14, 2012, 02:30:48 PM

lol i dont deserve them atall, Im screwing around Roll Eyes

(lol) Awww c'mon I gave the solution first(lol kinda) D&T just elaborated and made it a step by step guide (snickers) I want those coins! c'mon he's got 6gh/s i've got 1 xD

JackRabbit:

1. All you said was the SDK 2.6 is my problem. So was your solution to roll back my drivers, reintroducing the 100% cpu bug? not to mention that with the old drivers you need dummy plugs . (btw i have about 10, anyone need one?)

2. You mentioned nothing about switching bin files in the cgminer install. which by the way is an elegant and quick solution, took literally 1 minute

do you still think you deserve the coins with "If not, SDK2.6 is your problem." ?

No, Ofcourse i do not deserve the coins, Send them to D&T I was messing around in a vain attempt to get a coin, But cleary the joke was not projected properly

jjiimm_64

legendary

Activity: 1876

Merit: 1000

Quote from: Fiyasko on January 14, 2012, 04:02:33 AM

Quote from: jjiimm_64 on January 14, 2012, 03:25:41 AM

Quote from: Fiyasko on January 14, 2012, 03:15:49 AM

Lets get the obvious questions out of the way
Could your drivers have updated recently?
Your Obviously talking about the newer version of CGminer right? If not, SDK2.6 is your problem.

yes, i updated the ccc a month ago to get rid of the 100% bug. i have 11-12_vista64_win7_64_dd_ccc_ocl.exe

if I run the older version of cgminer, i get the normal hashrates. This did not affect the other 14 rigs running linuxcoin

Who wants to jump in, Thats fucked

then, after DAT 'jumped in'.

Quote from: Fiyasko on January 14, 2012, 02:30:48 PM

(lol) Awww c'mon I gave the solution first(lol kinda) D&T just elaborated and made it a step by step guide (snickers) I want those coins! c'mon he's got 6gh/s i've got 1 xD

JackRabbit:

1. All you said was the SDK 2.6 is my problem. So was your solution to roll back my drivers, reintroducing the 100% cpu bug? not to mention that with the old drivers you need dummy plugs . (btw i have about 10, anyone need one?)

2. You mentioned nothing about switching bin files in the cgminer install. which by the way is an elegant and quick solution, took literally 1 minute

do you still think you deserve the coins with "If not, SDK2.6 is your problem." ?

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 703. (Read 5805728 times)