Feda /dev/ - No Javascript allowed

#37833 pero que dev si llevan varios post con matemáticas xD

#37839 pues si has entendido las mates basicas no hay mas:

no hay nada que aclarir. o tienes una frecuencia de 0.02 o un periodo de 0.02. que esot no es sacar minimos ni maximos de ninguna funcion xq eso te da igual. el maximo y el minimo te saca el rate instantaneo, f(t).

y "tu dijiste" que tendrias 2B concurrentes por s. entonces yo interprete estos resultados correctamente. pero no tienen mucho sentido... matematicamente hablando hacer esa "aproximacion"...

que luego me has dado la razon, que fui yo el que interprete mal y los 0.02ms y los 2B/s no estan relacionados. ok.

pero las mates siguen siendo las mismas.

#37839JuAn4k4:

además de tener C=1 y asumir que para C=2 la L es la misma. Porque una repercute en la otra directamente.

en las mates? no. no se si te refieres al mundo real que si, pero en las mates ya te he demostrado que no. porque la L la usas despues de calcular el area.

C no es un factor lineal de L. (creo que se dice asi). no tienes una relacion C = 1 / L o L = 1 / C o como sea como tienes con el T.

si tengo 100 pcs y mando a 1 paquete por segundo. porque a 1000pcs no mando a 1 paquete por segundo?

tanto T como la L es fija. que es lo que llevamos dando vueltas desde el primer post. por tanto te queda la C y el rate/throghput final (sobre T).

#37839JuAn4k4:

pero desde el primer post te dije que esos 20ms van cambiando según la concurrencia que tengas.

bueno, desde el segundo post lo fije y te dije si ese numero es asi el resto no cuadra.

y esto si lo quieres calcular debes tener una funcion de l(c) para un periodo de 1 segundo.

asi puedes operar usando calculo.

si me das la funcion de latencia(concurrencia) te lo hago en 1 segundo

Si tengo que volver a hablar de release models en git me pego un tiro.

#37845 a mí personalmente en la situación que estoy me gusta trunk based como git process y utilizar release branches para las releases. No tengo una opinión fuerte pero de usar algo prefiero usar algo simple e ir iterando según la cultura del equipo y el estado de los sistemas que mantienen. Si ese "simple" es git flow pues git flow.

El caso es que ya he hablado fácil 4 veces en los últimos meses de que si usas trunk based sin release branches estás obligado a que el estado del trunk sea production ready, porque si no estás condicionando una release (en especial hotfixes) en base a ítems de trabajo (commits) que no tienen por qué tener relación alguna. Y a mí me da igual pero no sé si estoy muy equivocado, me explico muy mal o la gente no es capaz de entender algo tan sencillo, pero en caso de ser cualquiera de las dos primeras nadie me ha replicado nada.

#37846 #37846 La OCA (una organización que lleva cientos de repos con contribuciones externas de todas partes) simplemente mantiene como "master" las ramas de cada versión y luego cada contribución va en PR contra la "master" que toque.
El "truco" está en el uso de "git-aggregate", una herramienta creada por una empresa que trabaja con el ecosistema de OCA. Gracias a esta herramienta esa rama de "dev" la puedes crear al vuelo... por lo que puedes mantener un estado del proyecto a tu antojo con PR's aún no fusionados a la master que toque.

#37851 Aquí el tema es la imposición de un modelo a toda clase de proyectos... y no creo que exista la formula de la coca-cola.

OCA es un proyecto modular.... en la rama "master" tienes módulos en distintos estados y versiones... no puede existir un OCA 12 0.0.76 ... algo así, si lo quieres, lo logras fijando hasta que commit del histórico quieres leer. Pero no veo que mente perturbada querría algo así xDD por eso en los módulos se define también para poder trabajar con pypi (algo que no gusta a todo el mundo... coste mantenimiento vs beneficio real).

#37857 Osea si. Toda la razon. 40M de conexiones para tener 2B/s. O 2B de conexiones a 100B/s. A 0.02.

Pero 2B/s a 0.02 con 2B de conexiones NO.

Perdona, me he liado en algun momento en eso si HAHA

Pero en los primeros posts lo dije bien.