[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-smp
Subject:    Re: Newbie for SPM's
From:       Siddharth Srivastav <siddy () serc212 ! serc ! iisc ! ernet ! in>
Date:       1999-11-28 19:39:13
[Download RAW message or body]



On Sun, 28 Nov 1999, Mark Hahn wrote:

> 
> I presume you mean "reducing the per-frame encoder latency".
>>>> True, further, we are more constrained by the amount of data we are
pumping onto the N/W for
   (Resolution)*(Luminance+subsampled_chrominance)*(frame/s)
   640x480*(1+0.5)*(30)bytes per sec.(approx 105 Mbit per sec)
for real time encoding. The code optimization has been stretched to the
limits, and a failure to achieve the desired led us to turn our attention
to SMPs. Till now we have been designating tasks to machines across the
network and were not getting the performance.  
> 
> this might be a good idea, and might not.  SMP shares a fixed dram
> bandwidth, so if your encoder has a poor cache hitrate, SMP will not
> work well.
>>The cache hit rate is poor, since it is a real time capture, and frames
once encoded are overwritten. We were of the notion that SMP's would mean
putting the same computing power as a N/W of machines, with a low network
overhead, as we can do bulk disrtibution of data at peak rate.
Please comment. 

> there are none.  you just buy any SMP box on the market, and run Linux
> on it.  you need a kernel compiled for SMP, but that's trivial.
>> 
> 
>>>> 
> no change, unless you want multiple processors working on the same
> video stream.  if that's the case, the simplest solution would be 
> to alternate frames on each processor.  this does require some change
> to your programming, since you need to use threads.  threads are a
> standard interface universal in the Unix world (of course, Msft chose
> to ignore this standard for Win32, but they did so for political reasons.)
> >>>
  Moreever, we also want a tighter processor affinity, so that we can bind
processors to processes. We would want the individual processors to encode
a Gop each, and would be distribution data likewise. Is this possible with
the current kernels?
>>>>>>
> to your slowness?  IO is another resource that mostly doesn't scale on SMP.
>>>>>>
>>why? Ive heard of similar problems for SMP where all processors share
the same BUS, but arent there other versions avaliable with a seperate bus
for each procesor? Sorry if this question sounds naive.

-----BEGIN GEEK CODE BLOCK------
Version: 3.1
GE/IT/CS/O/U/! dpu s: a->? C+++ UBLAHIOS P+ L+++ !E--- W++>+++ N o? K++
w--- O- !M V PS++ PE++ Y+ PGP- t++ 5? X R-- !tv b++>+++ DI? D++ G+++
e+++>++++ h* r- !y+
-----END GEEK CODE BLOCK------

*************************************************************************
"Theirs not to reason why; theirs but to do...."
Tennyson, "Charge of the Light Brigade"
*************************************************************************
+------------------------------------+
| Siddharth Srivastav                |
| Multimedia Systems Lab.            |
| Indian Institute of Science        |
| Bangalore 560012                   |
| India                              |
| siddy@mmsl.serc.iisc.ernet.in      |
| siddy@mailcity.com                 |
+------------------------------------+



-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu

[prev in list] [next in list] [prev in thread] [next in thread]