search for: 4000k

...her hand, when I try to do the same on a PC (128 M RAM, 400MHz), running Linux (Redhat 6.1) , on R version 0.90.0, I find that it is impossible. When I allocate (what I believe to be) the maximum amount of vsize memory and a large amount of nsize memory R --vsize 200M --nsize 4000k, and then try to read the file in using read.table() or scan() myData <- read.table(file = "mydata.dat") or myData <- scan(file = "myData.dat", what = list("",0,0,...,0)) (with 29 zeros) I get kicked out of R. Mo...

...se it cannot allocate a new segment of about 500K of memory. I don't have Visual Basic so i cannot use the other commands suggested in Help. Also, if i am using memory.size(max=TRUE) i get a value corresponding to about 1024K, and if i am using memory.limit(size=NA) i get a value of about 4000K. How can i force R to use more memory? thank you for any suggestion, Monica Monica Palaseanu-Lovejoy University of Manchester School of Geography Mansfield Cooper Bld. 3.21 Oxford Road Manchester M13 9PL England, UK Tel: +44 (0) 275 8689 Email: monica.palaseanu-lovejoy at stud.man.ac.uk

OK just out of curiosity I used the smbclient prog from FreeBSD to check upload and download speeds... downloading from win to unix gets ~3000k/sec and uploading from unix to win gets ~4000k/sec so the only problem is uploading from win to unix where it's like ~300-~400k/sec... It must be how xp sends its files not a prob with the server... does anyone know where this would be set and what it may be??? thanks again, Tsidorus

...'m using loopback interface. # Set interface 0 i 0 lo 0 i 1 lo # Set packet size 0 S 0 1k 0 S 1 1k # Determine flow id 0 P 0 0x10006 0 P 1 0x10007 # Start flow... 0 R 0 4000k 0 R 1 4000k # Finish it. 10000 X 0 0 Foxtrot ethloop # ethloop < input > output When it finish, I got weird output. When I see the tc stat, the flow enters the right class but the rate is terribly wrong... I wonder what happen to it? Here''s the ou...

...em was not related to the Windows port (as the original author implied) but to the amount of memory R was started with. I just ran some tests on this I have to report that I am getting crashes every time I try this problem. (1) On my WinNT machine I got up to Rgui.exe --vsize=220M --nsize=4000k which produces > gc() free total (Mb) Ncells 3857498 4000000 76.3 Vcells 28790374 28835840 220.0 and it still crashes with the "referenced memory cannot be read" message. I also noticed that the error message comes immediately, no matter how large the memory al...

...of all, the help doesn't say what are the memory limits of R. Say, what's the max heap size for instance ???? Secondly, I invoke R with the following commands each time: rgui --vsize 30M --nsize 1000K rgui --vsize 30M --nsize 2000K rgui --vsize 30M --nsize 3000K rgui --vsize 30M --nsize 4000K I try to open a matrix 8000x8000 by issuing x<-matrix(nrow=8000,ncol=8000) I always get the following message: Error: heap memory (20480 Kb) exhausted [needed 250000 Kb more] It's always 250000 Kb less. Although gc() reports the memory management as expected (correctly ?), increased e...

On 05/25/2016 09:54 AM, Kelly Lesperance wrote: > What we're seeing is that when the weekly raid-check script executes, performance nose dives, and I/O wait skyrockets. The raid check starts out fairly fast (20000K/sec - the limit that's been set), but then quickly drops down to about 4000K/Sec. dev.raid.speed sysctls are at the defaults: It looks like some pretty heavy writes are going on at the time. I'm not sure what you mean by "nose dives", but I'd expect *some* performance impact of running a read-intensive process like a RAID check at the same time you'...

Has anyone noticed 2.0.7 taking more memory per process than 2.0.6 ? Our 2.0.6 processes usually run at an RSS of 1500K, but in 2.0.7 it's creeping up to 4000K at which point our 2.0.7 server is swapping like crazy. Alan. ************************************************************************* Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the...

...nd Kafka 0.9, and that's when the trouble started. What we're seeing is that when the weekly raid-check script executes, performance nose dives, and I/O wait skyrockets. The raid check starts out fairly fast (20000K/sec - the limit that's been set), but then quickly drops down to about 4000K/Sec. dev.raid.speed sysctls are at the defaults: dev.raid.speed_limit_max = 200000 dev.raid.speed_limit_min = 1000 Here's 10 seconds of iostat output, which illustrates the issue: [root at r1k1log] # iostat 1 10 Linux 3.10.0-327.18.2.el7.x86_64 (r1k1) ? ?05/24/16 ? ?_x86_64_? ?(32 CPU) avg...

This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows it gives, 28%, 24%, 21%, 16% IOPS boost and 32%, 17%, 21%, 16% latency improvement for sequential read/write, random read/write respectively. Asias He (3): block: Introduce __blk_segment_map_sg() helper block: Add blk_bio_map_sg() helper virtio-blk: Add bio-based IO path for virtio-blk

This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows it gives, 28%, 24%, 21%, 16% IOPS boost and 32%, 17%, 21%, 16% latency improvement for sequential read/write, random read/write respectively. Asias He (3): block: Introduce __blk_segment_map_sg() helper block: Add blk_bio_map_sg() helper virtio-blk: Add bio-based IO path for virtio-blk

...n 05/25/2016 09:54 AM, Kelly Lesperance wrote: >> What we're seeing is that when the weekly raid-check script executes, performance nose dives, and I/O wait skyrockets. The raid check starts out fairly fast (20000K/sec - the limit that's been set), but then quickly drops down to about 4000K/Sec. dev.raid.speed sysctls are at the defaults: > >It looks like some pretty heavy writes are going on at the time. I'm not >sure what you mean by "nose dives", but I'd expect *some* performance >impact of running a read-intensive process like a RAID check at the sa...

.../25/2016 09:54 AM, Kelly Lesperance wrote: >>> What we're seeing is that when the weekly raid-check script executes, performance nose dives, and I/O wait skyrockets. The raid check starts out fairly fast (20000K/sec - the limit that's been set), but then quickly drops down to about 4000K/Sec. dev.raid.speed sysctls are at the defaults: >> >>It looks like some pretty heavy writes are going on at the time. I'm not >>sure what you mean by "nose dives", but I'd expect *some* performance >>impact of running a read-intensive process like a RAID...