Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít. :PHix, lẽ ra phải lưu ý là các mods nên là những người post cuối cùng :P , 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 wrote:Thì anh chỉ phát biểu một câu "mờ mờ nhân ảnh" vậy để tham gia thôi mà :P. Câu đó chẳng có gì cụ thể hết.]]>
Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít. :PHix, lẽ ra phải lưu ý là các mods nên là những người post cuối cùng :P , 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 ạ. ;)
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 :D đạ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 :-) ...........Vâng, cám ơn góp ý của bạn. Thực ra thì với những traffic lớn giữa 2 sites, các data packets đều xấp xỉ MTU nên chúng tương đối bằng nhau. Mình xin lưu ý là ở đây mình chỉ quan tâm đến traffic giữa 2 sites thôi, còn với Internet bên ngoài thì mình không quan tâm lắm, vì dù sao nhân viên đến đây để làm việc là chính. Vì vậy theo mình là tương đối fair. ]]>
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 :D.Vâng, ý tưởng của bạn thì về mặt tổng quát rõ ràng là hay hơn trong đề bài, nhưng trong trường hợp như đề bài thì việc chia sẻ load giữa 2 thuật toán không khác nhau là mấy, khi mà lượng outgoing traffic khi không cần thì rất nhỏ, khi cần thì bao giờ cũng lớn hơn total bandwidth. Tuy nhiên, kể cả khi thay thuật toán của bạn vào thì câu trả lời của mình cho vấn đề hầu như không thay đổi. MrNothing wrote:
Ở 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?À, thế này cho dễ hiểu. Bây giờ mình chọn statistically uniformly random giữa 4 số 1, 2, 3, 4. Nếu số 1 được chọn thì mình gửi packet đi kết nối cũ. Còn lại thì mình gửi đi kết nối mới. Như vậy chắc bạn hiểu rồi chứ. Bạn lưu ý là câu hỏi của mình không đòi hỏi phải tính performance của hệ thống, mà là so sánh một cách tổng quát giữa tình hình hiện tại và trước kia, tức là đã bỏ qua rất nhiều các yếu tố kĩ thuật như lượng traffic mỗi ngày, distribute ra sao, vì chúng vẫn như nhau trong cả 2 trường hợp mới và cũ. Tất nhiên, khi tính toán yêu cầu về bandwidth cho kết nối mới, các kĩ sư đã suy nghĩ cẩn thận để đảm bảo kết nối chấp nhận được. Ví dụ: nếu kết nối cũ là 1MBps và mới là 3MBps, thì ắt hẳn traffic đòi tại burst time (xảy ra thường xuyên) cũng không quá 10MBps, nhưng nếu chỉ với một kết nối cũ 1MBps thì hiển nhiên khá là chậm.]]>
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.Bạn so sánh như vậy mình thấy có một số vấn đề sau: - Việc một người đi đường Lê Lợi hay Lê Lai là do người đó quyết định, còn việc một packet đi đường nào thì không phải do nó quyết định. - Một packet có thể bị mất trong network, một người thì không. - dòng người đi trên đường là đi một cách ồ ạt, còn packets di chuyển trong network thì không như vậy, mà có hàng lối của chúng. Theo bạn những vấn đề trên có thể tạo ra sự khác biệt nào không? rongchaua wrote:
Ý tưởng của bạn khá thú vị. Bây giờ mình thử làm một vài tính toán xem thế nào. Để cho đơn giản, mình giả sử như sau: - Kết nối cũ có bandwidth là 5MB/s, và kết nối mới là 15MB/s. - Kết nối cũ có RTT là 200ms và mới là 50ms. - Ta muốn gửi một file 1GB. Trong trường hợp đầu, tức là chỉ có một kết nối cũ, tức là bandwidth = 1 MB mỗi 1/5s. Do 1/5s này bằng với RTT, nên ở mức tối ưu, TCP có thể cho phép chuyển 1MB mỗi RTT. Như vậy delay để chuyển 1MB cho đến khi sender có thể chuyển 1MB tiếp theo = RTT + 1MB/bandwidth = 400ms. Như vậy thời gian để gửi đi 1GB sẽ là 400 * 1000 = 400000ms = 400s. Trong trường hợp thứ hai, tức là cũ + mới, khi chuyển 1MB, thì 3/4MB sẽ đến trước, và 1/MB sẽ đến sau, nên RTT để chuyển 1MB này là RTT của kết nối cũ, tức là 200ms. Trong khi đó, do tổng bandwidth là 20MB/s, nên trong 1 RTT = 200ms, TCP có thể cho phép chuyển tới 4MB. Như vậy delay để chuyển 4MB cho đến khi sender có thể chuyển 4MB tiếp theo là RTT + 4MB/bandwidth = 400ms. Như vậy thời gian gửi đi 1GB sẽ là 400 * 1000/4 = 100000ms = 100s. So sánh cả hai trường hợp thì mình thấy trường hợp thứ 2 vẫn cho kết quả khả quan hơn nhiều. ]]>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. :D.
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.Tính toán thế này thì không được, giả dụ trong trường hợp bị cắt làm 1/4:3/4 đi nữa, thì 3/4 file chạy với đường truyền mới, sẽ rất nhanh, theo như lí thuyết của đề bài thì bằng 3x tốc độ đường truyền cũ. 1/4 còn lại chạy với đường cũ thì không thể nào chạy với thời gian truyền đi cả file, 1/4:1 mà. Dù sao nó vẫn nhanh hơn khá là nhiều nếu như được phân chia như vậy. 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. Xin hế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.--> bias random thì mình đã giải thích ở một post phía trên. Và không thể có chuyện một file chỉ đi trên kết nối cũ hoặc mới, mà phải là cả hai, theo tỉ lệ 1:3, trừ phi file đó quá nhỏ, cỡ vài trăm KB chẳng hạn. --> Vấn đề của mình là so sánh giữa hai trường hợp, chứ mình còn chưa nghĩ đến một giải pháp tốt bạn ạ. @choc_: mình thấy phán đoán của bạn khá thú vị, mình chờ giải thích của bạn.]]>
1/5 gửi ->
+--------cũ--------- [ ISP 1] --{ Internet }-- [ ISP 2 ] -------cũ--------+
VN subnet-- [router] | [router]-- NY subnet
+--------mới---------------------- [ ISP mới ]----------------------mới------+
4/5 gửi -> 1/5 đến -> 4/5 đến ->
1/4 gửi -> 1/4 đến
+--------cũ--------------cũ--------+
VN subnet-- [router] [router]-- NY subnet
+--------mới-------------mới------+
3/4 gửi -> 3/4 đến ->
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.Hì hì, không phải ngẫu nhiên mà mình lại cho một kết nối có bandwidth gấp 3 lần cái kia, và RTT thì chỉ bằng 1/4. Giá như cái mạng thực tế của bạn mà tương tự như vậy mà có kết quả tốt thì sẽ rất thú vị. myquartz wrote:
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.Thực ra mình đưa vấn đề lên không phải để đánh đố ai cả, mà mục đích chỉ là để mọi người cùng thảo luận, đưa ra các suy nghĩ và phản biện. Chứ nếu mình đưa vấn đề rồi giải đáp luôn, thì chẳng khác gì bảo các bạn đi đọc sách còn hữu dụng hơn. Sẵn bạn đã nhận xét ra là trung bình cứ một packet đi trên kết nối cũ thì có 3 packets đi trên kết nối mới. Như vậy theo bạn điều gì sẽ xảy ra ở phía receiver, và sau đó là sender? Và cái điều xảy ra đó dẫn đến ảnh hưởng thế nào đến tốc độ truyền dữ liệu? Ảnh hưởng đó lớn hay nhỏ? Nếu nhỏ thì có khả năng nào nó bị "từ bé xé ra to" không? Tất cả những điều ở trên đều chỉ xoay quanh câu chuyện TCP hoạt động ra sao, và nó xử lý những tình huống bất thường như thế nào thôi.]]>
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).Chính xác. Còn về giải pháp thì một trong các giải pháp như có bạn đã đề cập ở trên là cho phép mỗi TCP connection hoạt động chỉ trên một kết nối. Ngoài ra, một giải pháp khác là cấu hình kernel để tăng số lượng duplicate acks nhận được trước khi giảm cwnd. Một giải pháp nữa là delay packets ở kết nối mới để RTT của nó bằng với kết nối cũ (việc này hầu như không làm ảnh hưởng đến performance của network).]]>