Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít.  

conmale wrote:

Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít.  

Hix, lẽ ra phải lưu ý là các mods nên là những người post cuối cùng , vì mình cho rằng các bài post của mods rất có ảnh hưởng đến ý kiến của members.

Anyway, nếu bạn nào có ý kiến khác anh conmale dù ít hay nhiều mình mong các bạn đưa lên đây để cùng thảo luận, vì còn chưa biết ai đúng ai sai.

@conmale: cổ chai lớn rót rượu nhiều nhưng nếu rót không khéo thì khi rơi xuống ly sẽ bắn tung tóe, vừa phí phạm và có khi phải rót lại anh ạ.  

@conmale: cổ chai lớn rót rượu nhiều nhưng nếu rót không khéo thì khi rơi xuống ly sẽ bắn tung tóe, vừa phí phạm và có khi phải rót lại anh ạ. 

Câu hỏi đặt ra là: việc thiết lập trên đã cải thiện những gì trong communication giữa trụ sở và chi nhánh? Như thế nào? Và tại sao?.  

Theo em thì nếu vấn đề phân luồng băng thông (enforce per-flow fair bandwidth allocation) không ngon thì vẫn xảy ra hàng chờ trong các phiên giao thông như thường đại loại như các packet sẽ chạy loạn xà ngầu trong một phiên transmissions hoặc receive một gói tin >"<
3-3 thì cân bằng được chứ 1-3 chắc thằng nhỏ cho đi đường nhỏ, thằng to đi đường to
........... 

Cải thiện bao nhiêu thì còn phụ thuộc phân bố của các gói tin gửi đi trong ngày hoặc trong một khoảng thời gian nhất định. Sau đó tính giá trị trung bình gì đó. Em không thạo cái xác suất này lắm.

Em chọn thuật toán tham lam là: Đi đường to đã, khi đường to tắc ta chuyển sang đường nhỏ.

Đang đứng Mai dịch đường 32 còn rộng chán cứ phóng 32 qua cầu vượt mà lên Sư Phạm tán gái tội gì mà đi vòng vào khu Đồng Xa ra Trần Quốc Hoàn rẽ cổng sau Sư Phạm .  

Ở bài toán em nghĩ phát biểu vẫn còn thiếu.

Anh nói trọng số là 1 và 3. Bias random là như thế nào? Em nghĩ 3 với 1 chưa nói lên giải thuật điều khiển như thế nào. còn xem tốc độ, băng thông còn lại của 2 đường truyền nữa chứ? Ví dụ một số bọn đang chiếm rồi? phân bố số gói tin trong ngày so với băng thông thế nào?
 

Theo tớ thì cách giải quyết trên sẽ giải quyết được vấn đề : nếu thằng cũ out thì còn có thằng mới thay thế. Vấn đề tối ưu bandwidth thì có vẻ không đúng lắm. Chẳng hạn từ A đến B luc đầu đi đường Lê Lợi,bi giờ mớ thêm con đường mới Lê Lai . Dân đi đường Lê Lợi đông quá thì rẽ sang Lê Lai đi thôi.  

Câu hỏi đặt ra là: việc thiết lập trên đã cải thiện những gì trong communication giữa trụ sở và chi nhánh? Như thế nào? Và tại sao?.  

Hên xui. Với kiểu bias random 1:3 này thì 25% packet sẽ chạy với tốc độ đường truyền cũ và 75% chạy với tốc độ đường truyền mới. Ví dụ trong trường hợp xui: gởi 1 file đi, 1/4 file chạy bên line cũ, 3/4 còn lại chạy bên line mới. 3/4 file tới trước ngồi chờ 1/4 file tới sau để góp lại đủ 1 file. Thì coi như cả đám chạy với tốc độ đường truyền cũ. Trường hợp hên thì cả đám chạy trên line mới thì tới nhanh hơn. Vi hên xui như vậy nên trong trường hợp xui thì cũng chạy ít nhất với tốc độ line cũ (bỏ qua thời gian xử lý của router) còn hên thì chạy với tốc độ line mới cho nên là có cải thiện. Nhưng cải thiện bao nhiêu thì ... hem biết. . 

Hên xui. Với kiểu bias random 1:3 này thì 25% packet sẽ chạy với tốc độ đường truyền cũ và 75% chạy với tốc độ đường truyền mới. Ví dụ trong trường hợp xui: gởi 1 file đi, 1/4 file chạy bên line cũ, 3/4 còn lại chạy bên line mới. 3/4 file tới trước ngồi chờ 1/4 file tới sau để góp lại đủ 1 file. Thì coi như cả đám chạy với tốc độ đường truyền cũ. Trường hợp hên thì cả đám chạy trên line mới thì tới nhanh hơn. Vi hên xui như vậy nên trong trường hợp xui thì cũng chạy ít nhất với tốc độ line cũ (bỏ qua thời gian xử lý của router) còn hên thì chạy với tốc độ line mới cho nên là có cải thiện. Nhưng cải thiện bao nhiêu thì ... hem biết.  

Nói về câu trả lời của em, thực chất em cũng không hiểu được cái random bias là thế nào, nói trước là đua đòi mà . Nhưng nếu random thì có trường hợp một file truyền đi trên chính đường truyền cũ, hoặc chỉ sử dụng đường truyền mới, hoặc sử dụng cả 2 ---> tốc độ không thể ổn định. Có khi rất chậm, lại có khi rất nhanh, dĩ nhiên sẽ nhanh hơn so với lúc chưa triển khai đường truyền mới. Cứ giả sử như có ông A ngày 1 gửi một file 10MB với thời gian là 2.5s, ngày thứ 2 cũng gửi một file 10MB nhưng với thời gian là 8s, thể nào ông ấy không la toáng lên.

Theo em giải pháp này không thực sự tốt, nếu đã như thế thì ngắt luôn đường truyền cũ, giảm chi phí, tốc độ tăng lên mà còn ổn định.
 

Vậy thì câu trả lời mới của mình là: kiểu nối mạng này hoàn toàn chạy tốt, ở tốc độ tốt hơn khi chưa nâng cấp. Bởi bài toán thực tế mình đã từng thực hiện nó kiểu như thế này (trừ việc 2 kênh này 1 là leased line và 1 cái khác là MegaWAN - của VTN, ko phải Internet như ví dụ), cũng per-packet load balancing, sai khác nhau bandwidth, gấp 2 lần, và cả RTT cũng có sự chênh nhau, tuy không quá lớn. Mô hình chạy tốt, tuy không phải hoàn hảo (tốc độ kết nối không ổn định lắm, tăng giảm, nhưng luôn có min = kênh chậm hơn, tổng lại vẫn nhanh hơn). Dù sau đó mình chuyển sử dụng per-destination còn tốt hơn, khai thác hết tốc độ 2 kênh và rất ổn định tốc độ cho kết nối TCP. 

Với đề bài (giả sử và giải trên lý thuyết) của bạn, có 1 kết quả khác, mạng lại tồi hơn. Thì tốt nhất là bạn nên nói suy luận và giải thích ra.

Mình không thi sát hạch, không thi thố tài năng, chỉ sử dụng kinh nghiệm và kiến thức cá nhân để suy đoán cho 1 trường hợp. Coi đó là giải trí hoặc nếu có giúp ích cho người khác hiểu hơn. Chứ kiến thức bao la, thực tế vô vàn, chưa biết được ai nhiều ai ít, ai biết cái này cái nọ đâu. 

Theo bạn trong trường hợp này tình trạng gửi packet theo thứ tự 1,2,3,4 và nhận theo thứ tự 2,3,4,1 sẽ xảy ra liên tục, vậy thì ngay sau khi kết nối được thiết lập, trong pha Slow Start với congestion window (cwnd) khởi tạo với 1 segment
- cwnd = 1 segment , ssthresh = 65535 bytes --> oki sender nhận được 1 ack trả về
- cwnd = 2 segment , ssthresh = 65535 bytes --> oki sender nhận được 2 ack trả về
- cwnd = 4 segment , ssthresh = 65535 bytes --> lúc này có thể sẽ nhận được 3 duplicate ack hoặc là 4 ack

nếu nhận được 4 ack thì cwnd sẽ tiếp tục tăng theo hàm mũ cho đến khi nhận được 3 duplicate ack hoặc bị mất gói tin. khi đó ssthresh = 1/2 cwnd, và bắt đầu lại quá trình Slow Start hoặc Congestion Avoidance

Trường hợp với mạng như bạn nêu việc nhận 3 duplicate ack sẽ liên tục -->vậy thì ngay từ đầu việc truyền dữ liệu đã bị "vùi dập" bởi giá trị cwnd sẽ không thể lớn được mà rất nhỏ ( có thể là 1packet) ngay từ quá trình thăm dò khả năng đường truyền (Slow Start).