Confirmado: uno vé @hotmail y piensa....

... lo mismo que esta empresa de recursos humanos al momento de contratar especialistas de Internet y afines:

Link: Catorze.blog - Blog Archive - El criterio Hotmail

Así que ya sabés: no pongas ese @hotmail en tu Currículum :-P

[en] powerful arrays in bash

Doing some experiments with advanced bash array features. I created a bash implementation of insertion sort algorithm.

UPDATE: This example is already part of the great Advanced Shell Scripting Guide :)

Enjoy :-D

#!/bin/bash
# insertion-sort.bash.sh: Insertion sort implementation in bash
#                         Heavy use of bash array features: slicing, merging, etc
# URL: http://www.lugmen.org.ar/~jjo/jjotip/insertion-sort.bash.d/insertion-sort.bash.sh
#
# Author: JuanJo Ciarlante  jjo \O/ irrigacion gov ar
# License: GPLv2
#
# Test with:   ./insertion-sort.bash.sh -t
#

: ${DEBUG:=1}  # debug, override with:  DEBUG=1 ./scriptname ..

# Global array: "list"
typeset -a list
# Load whitespace separated numbers from just stdin 1st line
if [ "$1" = "-t" ];then
     read -a list < <(od -An -w32 -t u2 /dev/urandom )
else
     read -a list
fi
numelem=${#list[*]}

# Shows the list, marking the element whose index es $1 by surrounding it with
# the two chars passed as $2; whole line prefixed with $3
showlist() { echo "$3"${list[@]:0:$1} ${2:0:1}${list[$1]}${2:1:1} ${list[@]:$1+1}; }

# loop "pivot" from 2nd elem, to end of list
for((i=1;i<numelem;i++))do
     ((DEBUG))&&showlist i "[]" " "
     # From current "pivot", back to 1st elem
     for((j=i;j;j--))do
             # search for the 1st elem less than current "pivot" ...
             [[ "${list[j-1]}" -le "${list[i]}" ]] && break
     done
     ((i==j)) && continue ## no insertion was needed for this element
     # ... move list[i] (pivot) to the left of list[j]:
     list=(${list[@]:0:j} ${list[i]} ${list[j]} ${list[@]:j+1:i-(j+1)} ${list[@]:i+1})
     #         {0,j-1}       {i}       {j}        {j+1,i-1}              {i+1,last}
     ((DEBUG))&amp;amp;amp;&showlist j "<>" "*"
done
echo $'Result:\n'${list[@]}

sistemas criticos funcionando con sistemas operativos de juguete (?)

Si sirve de consuelo ... ver que no solamente en estos lares abunda la mediocridad en quienes toman decisiones de IT.

"Quebec health officials are battling a fast-spreading virus that struck its entire computer network system late Tuesday." link

Lisp? nahh...

M'rd Donalds ... por qué lo amaré tanto ?

Si un día viendo tele sentís un deseo irresistible de transarte al "payasito" de M'rd Donalds quizás sea por algo como ésto (T=00:35).

Quién te dice ... por ahí terminás siendo un existoso manager, así que podés ir entrenando



Enjoy :-P

[en] Throughput tests WRTSL54GS v1.1 vs WRT54GS v3.0

Throughput tests WRTSL54GS v1.1 vs WRT54GS v3.0

The goal of this test is to measure and compare the NAT'ing/routing/switching behavior of these two WRT54G's [1] running OpenWRT Whiterussian RC6 [5]:

model	s/n	CPU	flash/RAM	eth switch
WRTSL54GS v1.1 [2]	CJK11xxxxxxx	Broadcomm 4704rev9 266Mhz	8/32MB	inCPU
WRT54GS v3.0 [3]	CGN5xxxxxxx	Broadcomm 5352 200Mhz	8/32MB	BCM5325

IMPORTANT: nbd ( openwrt developer) pointed a problem with "entropy gathering which fills /dev/random from wifi" in WR rc6 and suggested me trying a newer build (09test); I'll try it an repost the results (specially the wifi ones)
--jjo; Jan 10, 2007.

Testbed, methodology

• Topology



                       --------> iperf test connection------>
 WIFI-NATed    [CLIENT]+)) wifi (( +[ WRT ]+=== wan ===+[SERVER]   (iptables MASQUERADE'd)
 LAN-NATed     [CLIENT]+=== lan ===+[ WRT ]+=== wan ===+[SERVER]   (iptables MASQUERADE'd)
 LAN-routed    [CLIENT]+=== lan ===+[ WRT ]+=== wan ===+[SERVER]   (plain routing)
 LAN-switched  [CLIENT]+=== lan ===+[ WRT ]+=== lan ===+[SERVER]   (hardware switching)
           
 "lan": any LAN (1of4) port
 "wan": WAN port
 "wifi": 802.11g link at 54Mbps (aprox 2mts distance between antennas)
 iptables MASQUERADE'd: default whiterussian setup (masquerade both wifi,lan to wan)
 plain routing: accomplished with iptables full "flushing" + server route to client via WRT



• Hardware
  
  
  
  • client: IBM Thinkpad T42, lan: e1000 (10/100/1000), wifi: ipw2200
    
  • server: generic PC sempron 2200+, lan: 8139too
    
  • routers: (stated above)
    
  
  


• Software
  
  • client, server: iperf [4] (-c, -s) on linux-2.6, glibc-2.3+.
  • routers: OpenWRT WhiteRussian RC6 [5].

Results

Throughput values in megabits per second taken from iperf's output. Please note that measured rates by iperf correspond to _application_, ie: they don't consider protocol headers, etc.

CPU usage % shown by top for ksoft_IRQd from a ssh logged session, this "top" session was not considered for throughput values (separately taken) to avoid "measuring load influence": 100% CPU usage was aprox= 90% ksoft_IRQd + 8% dropbear + 2% top.

Throughput (CPU usage %)

model	WIFI-NATed	LAN-NATed	LAN-routed	LAN-switched
WRTSL54GS	23.5mbit/s (65%)	47.5mbit/s (90%+)	55.8mbit/s (90%+)	93.7mbit/s (0%)
WRT54GS	10.5mbit/s (14%)	34.2mbit/s (90%+)	40.4mbit/s (90%+)	93.8mbit/s (0%)

Analisys

WRTSL54GS

WIFI-NATed at 23.5 mbits (802.11g @54Mbps) with ~65% CPU usage denotes "reasonable" CPU availability for this 802.11g saturated link.

LAN-NATed at 47.5 mbits shows the CPU bottleneck when routing+MASQUERADING, considering that ip_conntrack table has just a few entries this is a VERY optimistic max.

LAN-routed at 55.8 mbits is pretty poor, I think that ip_conntrack processing is ALSO affecting this scenario (if loaded it gets called even for non-nated streams); it would be veryVERY useful to have ip_conntrack optionally loaded by openwrt (currently static).

LAN-switched at 93.8 mbits is expectable given that hardware only switching is involved.

WRT54GS

LAN-NATed and LAN-routed values give about 75% when compared to its newer cousin, 75% is roughly 200/266, respective CPU clocks [MHz] (this confirms CPU saturation).

WIFI-NATed at 10.5 mbits (dbl-confirmed 802.11g @54Mbps) is a bad smelling frog, I double checked openwrt setup... nothing strange found; about 1mo ago I was running RC5 getting ~20mbits+ rates (informal, from rsync/ftp rates), so it maybe something with RC6 wifi in this hardware, dunno(?).

As expected, LAN-switched gave same results.

Conclusions

Both WRT's seem reasonable for 802.11g @54Mbps even when NAT'ing traffic (common usage), obviously depending on traffic patterns, how many clients, etc ... given the constrained RAM (and CPU) for NAT+conntracking ... NOT tested here.

On the contrast, their CPU is not powerful enough to saturate _both_ (LAN+WAN) 100mbps links simultaneously, even when "only" routing (55mbit/s max on WRTSL54GS); this could be enhanced by having ip_conntrack optionally (not)loaded by openwrt.

Out of band disclaimer

Ok ... I know, you agree: blogger sucks for writing technical reports .. sheesshhhh :-P

References

[1]http://en.wikipedia.org/wiki/WRT54G
[2]http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRTSL54GS
[3]http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54GS
[4]Iperf bandwidth measurement tool: http://dast.nlanr.net/Projects/Iperf/
[5]http://downloads.openwrt.org/whiterussian/rc6/


This thread at openwrt forums talks about openwrt experiences on Linksys WRTSL54GS model, and was the starting point to encourage loading openwrt on WRTSL54GS v1.1 model.

[devel] multi process posix mutex

Jugando con la posibilidad de usar los mecanismos de sincronización de POSIX para threads (pthread_mutex_t, sem_t, pthread_cond_t , etc) llegué a una mini aplicación que es capaz de crear un MUTEX multiproceso de "larga vida" mediante el uso de memoria compartida:

    ./mproc-mutex estelock i  #init
    ./mproc-mutex estelock l  #lock
    ./mproc-mutex estelock l  #lock again: will wait until unlock or signal (eg: Ctrl-C)
    ./mproc-mutex estelock u  #unlock

La clave del fuente está en las sig. líneas:

   int fd; char *p;
   fd=shm_open(argv[1], O_RDWR|O_CREAT, 0666);
   ftruncate(fd, sizeof(pthread_mutex_t));
   :
   p=mmap(NULL, sizeof(pthread_mutex_t), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
   :
   pthread_mutex_init(p, NULL) ;

Más explicaciones en el src: http://www.lugmen.org.ar/~jjo/jjotip/jjotip-mproc-mutex/mproc-mutex.c