lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 11 Jan 2013 16:40:06 +0200
From:	Ozan Çağlayan <ozancag@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Kernel driver vs libusb performance

> It all depends on what you want to do, but I really think that user vs.
> kernelspace is not going to be the real problem here.  Start with libusb
> and if you find that you are having problems, use 'perf' to see if the
> kernel part is really the problem.  I think you will find all of your
> time is going to be spent in the USB hardware itself, and the USB
> driver, once you get the data out of that, user vs. kernel is not going
> to be noticable at all.
>
> Best of luck, and I bet you, in the end, you pick a better hardware
> platform for your project (hint, go buy a Beaglebone, it actually works
> and the tiny increase in cost more than makes up for the time you will
> waste fighting the RPI hardware.)

My mainloop is sth like this actually:

(I never thought of multi-processing & multi-threading but I may give
a chance on cooperative multitasking using Python greenlets)

1. [Simultaneously]
  {Fetch 32bytes in 128Hz + Decrypt + Queue them} AND
  {Flicker 2 LEDs with 10Hz/7.5Hz respectively using GPIO}
    (This is the step I'm afraid off, I expect jitters of course but
up to a limit. I also think about trying RT-patched kernel if that
will help at all...)

2. Take FFT of the signal queued using SciPy (I timed this: It takes
230~ uS for FFT of 128 integers on Rpi)

3. Do some simple math on FFT'ed signal &&
    Send a command to another device over a USB-FTDI channel if some
threshold is attained.

You are right that Beaglebone brings a huge improvement with
acceptable increase in the price but what I'm trying to do is to show
people that
"Hey what you are doing on your decent 1000$ i7 desktop with Matlab
over Windows works on my 30$ Linux box using Python" and that is
exactly why I'm pushing the limits of the device.

Thank you very much :)

-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ