# Generated by: TstHWin v2.21b - Registered to LW6EOF
# On : 24/03/2008 11:16:34
# UTC: 24/03/2008 14:16:34
FRACK Configurando
8. Configurar FRACK en un switch BPQ es un dilema. Esto es muy dependiente de la configuracion del port y del tipo de datos. Nosotros tenemos que examinar las condiciones del canal de Radio, el numero promedio de usuarios en horas pico, el modo en que el TNC es operado, etc. Como ejemplo extremo es el efecto de usar un regular TNC en modo KISS en un canal de Radio congestionado. La computadora no tiene conocimiento de cuando el TNC esta disponible a transmitir el frame y debera arrancar el tiempo de FRACK inmediatamente, despues enviara el frame al TNC. El FRACK debe estar seteado a un valor igual a la suma del promedio del tiempo de delay en transmision del frame mas el largo del frame (2 segundos a 1200 bps) mas el normal (NEDA) FRACK para un port del tipó radio. Esto puede resultar en un valor como mucho de 20 segundos y usted puede imaginar cuan lento y pesado puede resultar en un canal congestionado y las frecuentes colisiones.
En el otro extremo, un port BPQ alimentando un port serial de nodo (NETROM) o una matriz de diodos, no tiene ningun significado, el FRACK puede ser seteado a 1 segundo. Otros tipos de ports naturalmente caeran en alguna parte en medio de estos extremos.
Un agregado a este dilema es la falta de conocimiento de como la computadora manipula el
FRACK. Esto requiere una serie de experimentos apropiados antes, nosotros podemos cambiar el valor de FRACK en diferentes condiciones. Nosotros conocemos como se manipula el FRACK en un TNC regular en modo KISS. Lo que necesitamos conocer es el modo de operacion para lo siguiente:
a/ TNCs operando BPQKISS con KISSOPTIONS=POLLED,CHECKSUM,ACKMODE.
b/ TNCs operando en modo DED HOST y G8BPQ modo HOST.
c/ Operacion con tarjeta interna HDLC como DRSI (puede ser
la misma como /b ??).
d/ Cualquiera que yo olvide???
Lo indicado hasta que nosotros podamos poner resultados de algunos experimentos, es setear el FRACK a 6 segundos (6000 milisegundos) en un tranquilo port de usuario LAN y links dedicados corriendo en modo KISS, 12 segundos en un ocupado port de usuario LAN y 15 segundos en un canal "ZOO". Si usted esta corriendo el modo KISS regular, por favor convierta a BPQKISS con lo cual permite al computador monitorear el buffer transmitido. Mejor seria si usted puede, convertir el TNC a un nodo TheNET y linkearlo al BPQ usando protocolo NETROM. (Esto no es posible si esta corriendo TPK u otros UI frames en el port de radio.) La mejor situacion es operar todos los ports por su facilidad como nodos TheNET. Luego usar el switch BPQ linkeado a una matriz de diodos como una interfaz multi-conexion con aplicaciones como un BBS.
MAXFRAME
9. Esto es una considerable controversia acerca del valor apropiado de MAXFRAME en una Red. NEDA tiene desde hace algun periodo recomendado MAXFRAME=1. Oros dicen que esto es ridiculo, que MAXFRAME=1 es ineficiente y pone lentos los links. Desafortunadamente ninguna de las partes pueden explicar su posicion con claridad, logica y proveer evidencia experimental. Permitamosnos examinar las posiciones.
La politica de NEDA's es que todos los usuarios tienen igual oportunidad de acceder a los recursos disponibles de una Red. En un port de no-usuario se tiene que esperar un largo tiempo para poner un frame transmitido o a recibir un frame de otro nodo o servidor. Esto es realizado por la configuracion L2 MAXFRAME=1 y seteando los parametros persistence y slottime a un valor adecuado hay mejores oportunidades para transmision al node. A 1200 bps un frame + TXD tipicamente empleara 2 segundos para enviarse. Asumiendo que hay 5 usuarios en el canal, recibiendo informacion del nodo o servidor, cada usuario no tendra que esperar mas que 10 segundos por frame. Si el MAXFRAME esta seteado a 4 por ejemplo, algun usuario tendra que esperar como maximo 30 segundos por su participacion. No es muy favorable. Nota: Este valor de MAXFRAME solo afecta las transmisiones hechas por el nodo o links de descargas al usuario. Todos los frames subidos al nodo son controlados por el parametro MAXFRAME en los TNCs de los usuari
os.
Los oponentes al MAXFRAME=1 quieren que esto este muy "afinado" para ports de 1200 bps pero para ports de 9600 bps, el valor debera ser mas alto. Despues de la discusion en la ultima reunion, yo propuse que para ports de alta velocidad, altos valores de MAXFRAME donde sea apropiado no exceder en una transmision al usuario los 2 segundos. MAXFRAME=4 o incluso =6 en ports de usuario de 9600 bps satisface este criterio. MAXFRAME=3 sera apropiado para ports de 4800 bps.
Setear MAXFRAME en un link fundamental es otra materia. NEDA sostiene otra vez que el MAXFRAME=1 asegura igual participacion de recursos de Red y tiene resultados de experimentos anteriores que soporta el reclamo de extremo a extremo de la Red que sea mas alto que MAXFRAME=1. Los oponentes cuentan que esto es el resultado de un largo numero de links lentos a 1200 bps en nuestra Red y que nosotros deberiamos instalar todos los links de alta velocidad, el NEDA sostiene que es una mala prueba. En este punto sin embargo, esto no es evidencia experimetal solida que pruebe ninguna de las dos. Esto es grande y se necesita seguir buscando en esta importante materia. Nosotros continuamos recomendando MAXFRAME=1 porque conocemos como trabaja
y no tiene serios efectos de detrimentos en la Red (network).
Esta es mi opinion de uno de los mas importantes factores en la perfomance de la Red de un extremo al otro de las Redes TheNET es como "se ahoga" se manipula y el efecto de estrangulamiento del flujo de datos de la Red. Esto es mi impresion (no estoy leyendo la documentacion original de NETROM) que si un link NETROM L4 ahogado debe llegar a un circuito para entregar estos datos , luego todos los circuitos seran manipulados como que el link L4 estara detenido esperando que ellos tengan bien limpios los destinos que no son afectados por el estrangulamiento. Sin embargo, como resultado de un reciente experimento "accidental", esto no prueba ser exacto, al menos no para sistemas TheNET y NOS (el "experimento" involucraba un circuito con mas que 20 nodos TheNET - ambos tipos X1J y 2.0x - entre extremos y un sistema de nodo Convers en un JNOS). Cada vez que un circuito era totalmente ahogado, otras corrientes movian las partes del mismo camino
sin impedimentos.
******************
Cambios y notas agregadas luego del encuentro de Mayo 95.
Tiempo de respuesta en un port de Red (NETROM)
10. Esto ha sido notado en que el tiempo de respuesta esta siempre activo cuando se esta linkeado a una matriz de diodos NET/ROM. Esto es diferente del port serial de un nodo NET/ROM:TheNET donde el tiempo de respuesta es ignorado. Un tiempo de respuesta significante en un port BPQ alimentando una matriz de diodos tiene el efecto de comunicaciones mas lentas en el port. Setee RESPTIME=0 para eliminar este efecto de lentitud. Seteando RESPTIME=0 no provocara tener ningun efecto de detrimento pero si usted desea experimentar mejor con un valor distinto de cero como por ejemplo 1 (milisegundo), puede hacerlo.
Unconnected NETROM Ports
11. Nuevos ports, especialmente configurados para NETROM, deben ser comentados hacia afuera o mejor asegurarse de poner un resistior pull-up en el conector serial. Varias instalaciones han tenido problemas con el switch trabado sin ninguna razon aparente.(Credit: W6GO report)
***************************************************
Llamado a la accion
Si usted tiene algunas mejores ideas, permitanos escucharlas. Mientras tanto todos los que esten corriendo BPQ pueden chequear con los parametros aqui mencionados para resolver serios problemas.
***********************
Fin del archivo
-------------------------
Copyright © 1996-1997 by North East Digital Association .(NEDA)
73 de LW6EOF
AX25 : LW6EOF@LW8DJW.#1824.BA.ARG.SA
E-mail : lw6eof@yahoo.com.ar