On Wed, Jun 18, 2008 at 06:14:20PM -0700, Greg Lindahl wrote:
> On Wed, Jun 18, 2008 at 03:11:54PM -0700, Greg Lindahl wrote:
>
> > Speaking of lm_sensors, does anyone have configs for recent SuperMicro
> > mobos? My SuperMicro support contact doesn't have ay idea, and running
> > sensors-detect l
USA and allowing encryption beyond the cracking capabilities of a 1st
year computer science student... ...hmmm
I remember how i did do big efforts to get vista ultimate bitlocker
to work.
On paper it sounds ok. AES 256 bits CBC.
The idea is : your usb stick has the encryption key and only t
On Wed, Jun 18, 2008 at 03:11:54PM -0700, Greg Lindahl wrote:
> Speaking of lm_sensors, does anyone have configs for recent SuperMicro
> mobos? My SuperMicro support contact doesn't have ay idea, and running
> sensors-detect leaves me with lots of readings which are
> miscalibrated.
Thanks to the
David Mathog wrote:
Joe Landman wrote:
[...]
Maybe it will mean more to you than it does to me...
% lsscsi --long
[8:0:0:0]tapeHP Ultrium 3-SCSI D21D /dev/st0
state=running queue_depth=32 scsi_level=4 type=1 device_blocked=0
timeout=900
Hmmm... queue_depth of 32? On a t
Hi Dave,
Probably the i/o is your limiting factor.
Using raid10 or something?
Ignore that factor 2 compression by the way, that's just marketing
paper.
My LTO-2 gets about 28MB/s uncompressed streamspeed, for compressed
files
(7-zip is far superior to anything else currently under linux
Joe Landman wrote:
> Have you adjusted the block size up? maybe try
>
> dd if=/dev/zero of=/dev/nst0 bs=8M count=1000
The tape has a 64Mb on board buffer and somewhere in the manual it said
that it shouldn't matter. But no, I have not tried that yet and will
do so tomorrow.
> This said, have
On Wed, 18 Jun 2008 at 8:24pm, Joe Landman wrote
David Mathog wrote:
If any of you have an LTO Ultrium-3 drive what kind of speeds are you
observing? On one Linux system here (kernel 2.6.24-19) we have an
HP Ultrium-3 attached to an Adaptec ASC-29320ALP U320 controller.
ISTR hearing some rum
Jim Lux <[EMAIL PROTECTED]> writes:
> In general, fundamental research is not subject to export controls, so
> if you frame your problem in terms of abstract mathematical problems,
> you're not going to be treading on any toes. However, start
> distributing it as "Jim Lux's superduper encryptor/p
David Mathog wrote:
If any of you have an LTO Ultrium-3 drive what kind of speeds are you
observing? On one Linux system here (kernel 2.6.24-19) we have an
HP Ultrium-3 attached to an Adaptec ASC-29320ALP U320 controller.
There is nothing else on that SCSI bus, termination and cable seem good.
G
Jim Lux wrote:
So.. if your (foreign person) buddy is designing thermonuclear devices
in their garage, and they complain about how slow it is to run the
hydrocodes to simulate stuff, better not hand them that old copy of
Sterling, et al., or even worse, give them rgb's website. (the latter
wo
If any of you have an LTO Ultrium-3 drive what kind of speeds are you
observing? On one Linux system here (kernel 2.6.24-19) we have an
HP Ultrium-3 attached to an Adaptec ASC-29320ALP U320 controller.
There is nothing else on that SCSI bus, termination and cable seem good.
Getting into scsi-selec
At 04:16 PM 6/18/2008, Vincent Diepeveen wrote:
Jakob,
Is it legal what your friend is doing for his hobby in his sparetime?
Thanks,
Vincent
There are many things that one might do, perhaps with a cluster, that
can get you into trouble with various treaties and agreements. For
example, the
Hi Greg:
On Wed, Jun 18, 2008 at 3:11 PM, Greg Lindahl <[EMAIL PROTECTED]> wrote:
> Speaking of lm_sensors, does anyone have configs for recent SuperMicro
> mobos? My SuperMicro support contact doesn't have ay idea, and running
> sensors-detect leaves me with lots of readings which are
> miscalib
On Wednesday 18 June 2008 04:31:21 pm you wrote:
> I'm glad you mentioned this. I've read through much of the
> information on their web site and I still don't understand the usage
> model for CUDA. By that I mean, on a desktop machine, are you
> supposed to have 2 graphics cards, 1 for running CUD
Not that this mailing list is an appropriate place to discuss this, but...
Vincent Diepeveen <[EMAIL PROTECTED]> writes:
> Treaty, if i read it well, makes problems using public key above 512
> bits.
>
> So according to that treaty, if i read it correct, trying to do anything
> with a SSH which u
Greg Lindahl wrote:
On Wed, Jun 18, 2008 at 10:51:04AM -0400, Prentice Bisbal wrote:
Someone made the inaccurate statement that CUDA programming is difficult
and time-consuming.
One data point cannot prove that CUDA is easy. There are people out
there claiming that FPGAs are easy to program,
Kilian CAVALOTTI wrote:
We've also encountered somme oddities, like CUDA code freezing a machine
running X.org (and using the proprietary NVIDIA driver),
I'm glad you mentioned this. I've read through much of the information
on their web site and I still don't understand the usage model for
CU
Jakob,
You are speaking here of a hobby project of a system administrator
to crack a few passwords in the slowest possible way?
In general very stupid algorithms do not benefit much from caching
things in RAM,
let alone caches and are lightyears slower than what is possible.
Game tree search
On Wed, Jun 18, 2008 at 10:14:28PM +0200, Vincent Diepeveen wrote:
> Prentice,
>
> No one doubts your collegue.
>
Ok the following has nothing to do with any part of the discussion, but I just
needed to get this out :)
...
> So this experiment of your high esteemed collegue is an example of an
On Wednesday 18 June 2008 02:46:04 pm Greg Lindahl wrote:
> One data point cannot prove that CUDA is easy. There are people out
> there claiming that FPGAs are easy to program, because they're one of
> the 7 people on the planet for whom programming an FPGA is easy.
>
> I've looked over CUDA and so
Speaking of lm_sensors, does anyone have configs for recent SuperMicro
mobos? My SuperMicro support contact doesn't have ay idea, and running
sensors-detect leaves me with lots of readings which are
miscalibrated.
-- greg
___
Beowulf mailing list, Be
In message from "Seth Bardash" <[EMAIL PROTECTED]> (Wed, 18
Jun 2008 10:32:17 -0600):
ftp://ftp.tyan.com/softwave/lms/2932.sensors.conf
Seth Bardash
Thank you very much !!
It's strange, but I didn't find this file on Tyan archive!
Mikhail
Integrated Solutions and Systems
1510 Old North G
Prentice Bisbal wrote:
Vincent Diepeveen wrote:
Running 128 parallel sessions of md5sum is not so interesting at all, we
all believe this can be done fast.
Vincent,
That is the whole point of my original posting. The point was NEVER to
demonstrate the use of GPUs for streaming MD5-encrypted
In message from "Seth Bardash" <[EMAIL PROTECTED]> (Wed, 18
Jun 2008 10:32:17 -0600):
ftp://ftp.tyan.com/softwave/lms/2932.sensors.conf
Seth Bardash
Integrated Solutions and Systems
1510 Old North Gate Road
Colorado Springs, CO 80921
719-495-5866
719-495-5870 Fax
719-337-4779 Cell
http://ww
On Wed, Jun 18, 2008 at 10:51:04AM -0400, Prentice Bisbal wrote:
> Someone made the inaccurate statement that CUDA programming is difficult
> and time-consuming.
One data point cannot prove that CUDA is easy. There are people out
there claiming that FPGAs are easy to program, because they're one
Vincent Diepeveen wrote:
>
> Running 128 parallel sessions of md5sum is not so interesting at all, we
> all believe this can be done fast.
>
Vincent,
That is the whole point of my original posting. The point was NEVER to
demonstrate the use of GPUs for streaming MD5-encrypted data. This was
the
Prentice,
No one doubts your collegue.
Taking a md5 is very fast on PC processors. The code is very simple.
Just a few lines of code it is.
At my raid10 array i take a lot of md5sums for big files (chess
endgame table bases),
the limiting factor is the i/o speed.
I/O delivers oh in my ca
Sorry, do somebody have correct sensors.conf file for Tyan S2932
motherboard ? There is no lm_sensors configuration file for this mobos
on Tyan site :-(
Yours
Mikhail Kuzminsky
Computer Assistance to Chemical Research Center
Zelinsky Institute of Organic Chemistry
Moscow
__
I seem to have muddied the waters of the original NVIDIA/CUDA post.
Someone made the inaccurate statement that CUDA programming is difficult
and time-consuming. I cited the MD5-example of my colleague as an
example of how easy it is to port the code, and how significant the
performance improvements
(I'm resending this as the first version had an html attachment that was
too big for this list)
If there are any experience HPC Sysadmins in the Raleigh-Durham area or
looking to move to it, please take a look at this job posting. We're
stepping up our HPC and Research Computing efforts and a
30 matches
Mail list logo
