Ctrl-C problem

cubaq · 2017-02-03, 17:12

Hi,

I tried to use nfs(C142) -R and single Ctrl-C does not stop process.
After second Ctrl-C some files are not empty but after execute same nfs results are deleted. There is no file nfs.dat.p build.
What I am doing wrong?

Config file:

B1pm1=100000
B1pp1=20000
B1ecm=11000
rhomax=1000
threads=8
pretest_ratio=0.25
%ggnfs_dir=..\ggnfs-bin\Win32\
ggnfs_dir=../ggnfs-bin/
R=1
%ecm_path=..\gmp-ecm\bin\x64\Release\ecm.exe
%ecm_path=../ecm/current/ecm
tune_info= Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz,LINUX64,1.73786e-05,0.200412,0.400046,0.0987873,98.8355,2699.98

Last lines of factor file:

02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, nfs: commencing nfs on c142: 7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249
02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, nfs: commencing poly selection with 8 threads
02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, nfs: setting deadline of 34875 seconds

Last line of session file:

02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, System/Build Info:
Using GMP-ECM 6.3, Powered by GMP 5.1.1
cached 78498 primes. pmax = 999983
detected Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
measured cpu frequency ~= 3501.625770
using 20 random witnesses for Rabin-Miller PRP checks
02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, New random seeds: 3880908406, 1666429196
02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, Processing expression: nfs(7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249) -R

Regards, cubaq

chalsall · 2017-02-03, 18:59

Quote:

Originally Posted by cubaq

I tried to use nfs(C142) -R and single Ctrl-C does not stop process. After second Ctrl-C some files are not empty but after execute same nfs results are deleted. There is no file nfs.dat.p build.
What I am doing wrong?

Not quite sure. I haven't looked at the source code.

Please see https://en.wikipedia.org/wiki/Unix_signal.

It is possible the program installed a signal handler which didn't preform well.

Just so you know, "kill -k" (SIGKILL) should remove the process from your system (unless it is "zombied"), and "kill -h" (SIGSTOP) should stop its CPU usage but will maintain it's RAM state (both states might be swapped out).

"Ctrl-c" stops most Unix programs at the console, but then other people decided it was a good idea to make that the keystrokes for the "Cut" before the Paste.

cubaq · 2017-02-03, 19:12

Hi,
yafu itself is handling Ctrl-C.

Regards

bsquared · 2017-02-03, 19:18

You have to be patient for ctrl-c to work, especially during poly select. Unfortunately so much garbage scrolls up the screen during poly select that it can be difficult to see this message. After two ctrl-c's it will force quit and not save ongoing results. So it is doing exact what it was designed to do.

chalsall · 2017-02-03, 19:57

Quote:

Originally Posted by bsquared

So it is doing exact what it was designed to do.

I hear you.

At the same time, if you receive a SIGINT it means someone wants you to hear them. And they want you to finish as best you can, and then stop.

Sometimes it's a human, but not always.

cubaq · 2017-02-04, 10:11

bsquared.

Thank you for your advice. I will do more tests.

Regards

cubaq · 2017-02-06, 19:10

Quote:

Originally Posted by bsquared

You have to be patient for ctrl-c to work, especially during poly select. Unfortunately so much garbage scrolls up the screen during poly select that it can be difficult to see this message. After two ctrl-c's it will force quit and not save ongoing results. So it is doing exact what it was designed to do.

bsquared,

I have made some tests, and results are as follow:

Attempt 1.

2017-02-04
11:06 run nfs("C142") -R
11:12 Ctrl-C
around 17:00 files are not empty in dictionary
nfs.dat.p 90K
around 18:55 Ctrl-C once more

Attempt 2. (with nfs.dat.p from previous attempt)

2017-02-06
10:29 run nfs("C142") -R
17:23 Ctrl-C
19:35 nfs-dat.p 304 K
20:04 Ctrl_C

I can proceed it further and I can't say Ctrl-C does not work, but it does seems to be
strange.

Regards,
cubaq

bsquared · 2017-02-06, 22:48

Are those times in hours:minutes or minutes:seconds?

Here is what I see in top after starting your number with 8 threads:

Code:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  622620  18020   1720 S 799.7  0.0   1:58.63 yafu             (about 15 sec)


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  610280  16820   1748 S 699.3  0.0  44:39.31 yafu                (about 334 sec)     


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  610088  12008   1752 S 300.3  0.0  55:52.26 yafu            (about 419 sec)


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  610024  10436   1752 S 200.7  0.0  61:09.03 yafu             (about 458 sec)   


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  609960   9276   1752 S 100.0  0.0  69:50.34 yafu             (about 523 sec)   

hashtable: 4096 entries,  0.06 MB
polynomial selection complete
R0: -3866072726681456260093881121
R1: 1391567416121857
A0: 81648821478453834525972848949921876
A1: 28456886984046537135946391613
A2: -395798735285794997588524
A3: -81287270776011760
A4: 388119837636
A5: 8784
skew 1170643.73, size 8.083e-14, alpha -6.852, combined = 1.437e-11 rroots = 5
elapsed time of 1184.3183 seconds exceeds 34875 second deadline; poly select done

As the threads finish their chunk of work they see the ABORT signal and save their work; as they do so the cpu load slowly drops off. After 9 minutes or so 7 of the 8 threads have finished. Another 10 minutes goes by until the last one finally finishes. At this point nfs.dat.p has results from all 8 threads. A second ctrl-c at any point during this procedure would keep anything that had already been written to nfs.dat.p.

I then resumed the job using -R:

Code:

>> nfs: checking for job file - no job file found
nfs: checking for poly file - poly file found, testing for matching input
nfs: poly file matches input
nfs: finding best poly in poly file
searching for best poly...
new best score = 1.251000e-11, new best line = 1
new best score = 1.252000e-11, new best line = 2
new best score = 1.273000e-11, new best line = 3
new best score = 1.307000e-11, new best line = 4
new best score = 1.335000e-11, new best line = 11
new best score = 1.355000e-11, new best line = 18
new best score = 1.401000e-11, new best line = 34
new best score = 1.437000e-11, new best line = 104
nfs: last leading coefficient was 10164
nfs: commencing nfs on c142: 7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249



  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
52532 buhrow    20   0  610088  18440   1736 S 799.3  0.0   9:43.64 yafu                 


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
52532 buhrow    20   0  610088  12040   1760 S 300.3  0.0  54:43.73 yafu           


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
52532 buhrow    20   0  610024  10820   1760 S 199.7  0.0  60:35.92 yafu                 



polynomial selection complete
R0: -3745208843448348126000190607
R1: 637630404522509
A0: 8510337105548027774873794177911474240
A1: 8588550391847037282101562065472
A2: -634125061790737193458364
A3: -1466890891928532188
A4: 83093269269
A5: 10296
skew 4732602.93, size 7.655e-14, alpha -7.744, combined = 1.380e-11 rroots = 5
elapsed time of 800.0167 seconds exceeds 34321 second deadline; poly select done

So again, threads finish, save their results incrementally to nfs.dat.p, and the cpu load slowly drops to zero over a period of about 12 minutes.

Note that the total time to be spent in poly select is 34321 seconds - about 10 hours. So a second ctrl-c that tosses 10 minutes of work is losing about 1/60th the total work.

Also note that the total time spent in poly select is written to the last line of the nfs.dat.p, so that when you resume yafu knows where you left off. After my resume stopped, my last line was

Code:

time: 8494

I also just remembered that there is a command line option that influences this behavior called "pbatch". It specifies the range of leading coefficients for each thread to search, defaulting to 250. Making it smaller will dispatch less work to each thread, in theory making them somewhat more responsive to ctrl-c (they should finish faster, save their results to nfs.dat.p more often, and also check the ABORT signal more often).

If you expect to ctrl-c often, you could try running as nfs("C142") -R -pbatch 100

cubaq · 2017-02-08, 12:23

Quote:

Originally Posted by bsquared

Are those times in hours:minutes or minutes:seconds?

Here is what I see in top after starting your number with 8 threads:

Code:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  622620  18020   1720 S 799.7  0.0   1:58.63 yafu             (about 15 sec)


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  610280  16820   1748 S 699.3  0.0  44:39.31 yafu                (about 334 sec)     


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  610088  12008   1752 S 300.3  0.0  55:52.26 yafu            (about 419 sec)


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  610024  10436   1752 S 200.7  0.0  61:09.03 yafu             (about 458 sec)   


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
22973 buhrow    20   0  609960   9276   1752 S 100.0  0.0  69:50.34 yafu             (about 523 sec)   

hashtable: 4096 entries,  0.06 MB
polynomial selection complete
R0: -3866072726681456260093881121
R1: 1391567416121857
A0: 81648821478453834525972848949921876
A1: 28456886984046537135946391613
A2: -395798735285794997588524
A3: -81287270776011760
A4: 388119837636
A5: 8784
skew 1170643.73, size 8.083e-14, alpha -6.852, combined = 1.437e-11 rroots = 5
elapsed time of 1184.3183 seconds exceeds 34875 second deadline; poly select done

As the threads finish their chunk of work they see the ABORT signal and save their work; as they do so the cpu load slowly drops off. After 9 minutes or so 7 of the 8 threads have finished. Another 10 minutes goes by until the last one finally finishes. At this point nfs.dat.p has results from all 8 threads. A second ctrl-c at any point during this procedure would keep anything that had already been written to nfs.dat.p.

I then resumed the job using -R:

Code:

>> nfs: checking for job file - no job file found
nfs: checking for poly file - poly file found, testing for matching input
nfs: poly file matches input
nfs: finding best poly in poly file
searching for best poly...
new best score = 1.251000e-11, new best line = 1
new best score = 1.252000e-11, new best line = 2
new best score = 1.273000e-11, new best line = 3
new best score = 1.307000e-11, new best line = 4
new best score = 1.335000e-11, new best line = 11
new best score = 1.355000e-11, new best line = 18
new best score = 1.401000e-11, new best line = 34
new best score = 1.437000e-11, new best line = 104
nfs: last leading coefficient was 10164
nfs: commencing nfs on c142: 7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249



  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
52532 buhrow    20   0  610088  18440   1736 S 799.3  0.0   9:43.64 yafu                 


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
52532 buhrow    20   0  610088  12040   1760 S 300.3  0.0  54:43.73 yafu           


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                    
52532 buhrow    20   0  610024  10820   1760 S 199.7  0.0  60:35.92 yafu                 



polynomial selection complete
R0: -3745208843448348126000190607
R1: 637630404522509
A0: 8510337105548027774873794177911474240
A1: 8588550391847037282101562065472
A2: -634125061790737193458364
A3: -1466890891928532188
A4: 83093269269
A5: 10296
skew 4732602.93, size 7.655e-14, alpha -7.744, combined = 1.380e-11 rroots = 5
elapsed time of 800.0167 seconds exceeds 34321 second deadline; poly select done

So again, threads finish, save their results incrementally to nfs.dat.p, and the cpu load slowly drops to zero over a period of about 12 minutes.

Note that the total time to be spent in poly select is 34321 seconds - about 10 hours. So a second ctrl-c that tosses 10 minutes of work is losing about 1/60th the total work.

Also note that the total time spent in poly select is written to the last line of the nfs.dat.p, so that when you resume yafu knows where you left off. After my resume stopped, my last line was

Code:

time: 8494

I also just remembered that there is a command line option that influences this behavior called "pbatch". It specifies the range of leading coefficients for each thread to search, defaulting to 250. Making it smaller will dispatch less work to each thread, in theory making them somewhat more responsive to ctrl-c (they should finish faster, save their results to nfs.dat.p more often, and also check the ABORT signal more often).

If you expect to ctrl-c often, you could try running as nfs("C142") -R -pbatch 100

bsquared,

Thank You for being patient with newby.

1. Times are in hours and minutes (I WAS patient).

2. Do we use the same nfs ?? Or do we use the same 'top of' ??

When I start nfs (nfs.dat.p empty) the "top of" is :
nfs(7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249) -R

nfs: commencing nfs on c142: 7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249
nfs: searching for brent special forms...
nfs: searching for homogeneous cunningham special forms...
nfs: searching for XYYXF special forms...
nfs: couldn't find special form
nfs: commencing polynomial search over range: 1 - 251
nfs: commencing polynomial search over range: 251 - 501
nfs: commencing polynomial search over range: 501 - 751
nfs: commencing polynomial search over range: 751 - 1001
nfs: commencing polynomial search over range: 1001 - 1251
nfs: commencing polynomial search over range: 1251 - 1501
nfs: commencing polynomial search over range: 1501 - 1751
nfs: commencing polynomial search over range: 1751 - 2001
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
coeff 12 specialq 1 - 251806 other 33046 - 79310
coeff 756 specialq 1 - 1741025 other 19019 - 45645
coeff 252 specialq 1 - 1042581 other 22020 - 52848
coeff 1512 specialq 1 - 2405895 other 17340 - 41616
coeff 1260 specialq 1 - 2209667 other 17767 - 42640
coeff 504 specialq 1 - 1440799 other 20076 - 48182
coeff 1008 specialq 1 - 1991024 other 18304 - 43929
coeff 1752 specialq 1 - 2577060 other 17003 - 40807
aprogs: 2973 entries, 3637 roots
aprogs: 2859 entries, 4155 roots
aprogs: 2902 entries, 4170 roots

When restart nfs (nfs.dat.p not empty) the top is :

nfs(7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249) -R

nfs: commencing nfs on c142: 7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249
nfs: searching for brent special forms...
nfs: searching for homogeneous cunningham special forms...
nfs: searching for XYYXF special forms...
nfs: couldn't find special form
nfs: commencing polynomial search over range: 468 - 718
nfs: commencing polynomial search over range: 718 - 968
nfs: commencing polynomial search over range: 968 - 1218
nfs: commencing polynomial search over range: 1218 - 1468
nfs: commencing polynomial search over range: 1468 - 1718
deadline: 400 CPU-seconds per coefficient
nfs: commencing polynomial search over range: 1718 - 1968
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
nfs: commencing polynomial search over range: 1968 - 2218
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
nfs: commencing polynomial search over range: 2218 - 2468
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
deadline: 400 CPU-seconds per coefficient
coeff 468 specialq 1 - 1391848 other 20275 - 48660
coeff coeff 720 specialq 1 - 1701677 other 19144 - 45945
coeff 1476 specialq 1 - 2378983 other 17396 - 41750
coeff 1740 specialq 1 - 2568734 other 17019 - 40845
984 specialq 1 - 1968703 other 18363 - 44071
coeff 2220 specialq 1 - 2877957 other 16475 - 39540
coeff 1968 specialq 1 - 2720647 other 16742 - 40180
coeff 1224 specialq 1 - 2179887 other 17836 - 42806
aprogs: 2727 entries, 3323 roots
aprogs: 3005 entries, 3721 roots
aprogs: 2696 entries, 3392 roots
aprogs: 2528 entries, 3176 roots
aprogs: 3229 entries, 4265 roots
aprogs: 2657 entries, 3369 roots
aprogs: 2904 entries, 3660 roots
aprogs: 2816 entries, 3520 roots
1476 212118662063 5523223211366157977516407419
1740 68108370011 5344413060859738028816948741
1476 3497302784437 5523223211366154278789577439
984 19567785579979 5989779658750505503257218874
2220 40175706389357 5090251861853342285531055778
468 228916151945873 6949614197095561485555105704
2220 41419602288757 5090251861853297269513946743
1740 4606787118857 5344413060859740380932812784
1224 93009673110263 5733945790657433722609522176
2220 80148455101 5090251861853232242350531002
1740 3189826496129 5344413060859737434713365319
2220 17483198163431 5090251861853253977110466319
1968 672115119964223 5214406055936111813449055084

3. Using pbatch with different combinations aborts yafu with no output given.
Or, maybe, I can't find.

Regards,

cubaq

chris2be8 · 2017-02-08, 16:54

There is a UNIX command called "top" which shows how busy the system is and which programs are using most CPU (among other things). bsquared was referring to output from it.

It's quite safe, so try running it and see what it says. Check the man page for it to see what else it can do (type "man top" to get the man page).

Chris

bsquared · 2017-02-08, 17:33

You are indeed being patient, if it still hasn't stopped after nearly 8 hours.

I had assumed, based on your .ini file (preference for ../ggnfs_bin over ..\ggnfs-bin\Win32\), that you were using linux, but maybe that's not the case.

I don't know why it would be taking so much longer on windows. Setting -pbatch smaller should still help the responsiveness, maybe you need to go as small as 20 or so.

2017-02-03, 17:12	#1
cubaq Mar 2016 111011₂ Posts	Ctrl-C problem Hi, I tried to use nfs(C142) -R and single Ctrl-C does not stop process. After second Ctrl-C some files are not empty but after execute same nfs results are deleted. There is no file nfs.dat.p build. What I am doing wrong? Config file: B1pm1=100000 B1pp1=20000 B1ecm=11000 rhomax=1000 threads=8 pretest_ratio=0.25 %ggnfs_dir=..\ggnfs-bin\Win32\ ggnfs_dir=../ggnfs-bin/ R=1 %ecm_path=..\gmp-ecm\bin\x64\Release\ecm.exe %ecm_path=../ecm/current/ecm tune_info= Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz,LINUX64,1.73786e-05,0.200412,0.400046,0.0987873,98.8355,2699.98 Last lines of factor file: 02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, nfs: commencing nfs on c142: 7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249 02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, nfs: commencing poly selection with 8 threads 02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, nfs: setting deadline of 34875 seconds Last line of session file: 02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, System/Build Info: Using GMP-ECM 6.3, Powered by GMP 5.1.1 cached 78498 primes. pmax = 999983 detected Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes measured cpu frequency ~= 3501.625770 using 20 random witnesses for Rabin-Miller PRP checks 02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, New random seeds: 3880908406, 1666429196 02/03/17 15:48:53 v1.34.5 @ WLODEK-KOMPUTER, Processing expression: nfs(7586637469462894284599484465884287014024041092607169175865381296539535723733497662367239852691147442960345873275024639010706535234522995742249) -R Regards, cubaq

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
dealing with nfs and Ctrl-C second stage)	cubaq	YAFU	2	2017-04-11 12:19
What is the problem here?	didgogns	Msieve	1	2016-11-15 03:31
Disable Ctrl Alt Delete Task Manager	TTn	Programming	31	2005-12-31 12:56
51 problem	Neves	Miscellaneous Math	5	2004-02-10 22:59
51 problem	Neves	Puzzles	15	2004-02-05 23:11

2017-02-03, 19:12	#3
cubaq Mar 2016 59 Posts	Hi, yafu itself is handling Ctrl-C. Regards

2017-02-03, 19:18	#4
bsquared "Ben" Feb 2007 3404₁₀ Posts	You have to be patient for ctrl-c to work, especially during poly select. Unfortunately so much garbage scrolls up the screen during poly select that it can be difficult to see this message. After two ctrl-c's it will force quit and not save ongoing results. So it is doing exact what it was designed to do.

2017-02-04, 10:11	#6
cubaq Mar 2016 59 Posts	bsquared. Thank you for your advice. I will do more tests. Regards

2017-02-08, 16:54	#10
chris2be8 Sep 2009 2,027 Posts	There is a UNIX command called "top" which shows how busy the system is and which programs are using most CPU (among other things). bsquared was referring to output from it. It's quite safe, so try running it and see what it says. Check the man page for it to see what else it can do (type "man top" to get the man page). Chris

2017-02-08, 17:33	#11
bsquared "Ben" Feb 2007 D4C₁₆ Posts	You are indeed being patient, if it still hasn't stopped after nearly 8 hours. I had assumed, based on your .ini file (preference for ../ggnfs_bin over ..\ggnfs-bin\Win32\), that you were using linux, but maybe that's not the case. I don't know why it would be taking so much longer on windows. Setting -pbatch smaller should still help the responsiveness, maybe you need to go as small as 20 or so.