Mạng internet

[falleaf]

Vấn đề đièu khiển qua mạng internet gặp rất nhiều khó khăn. Quan trọng nhất là delay. Một hệ thống internet gặp vấn đề delay thay đổi, và delay có thể từ 5ms (có thể xem là thời gian thực), đến 300ms (đường truyền quốc gia 10000km), và có thể tiến ra đến vô cùng (mất dữ liệu).

Có những phương pháp nào để giải quyết?

Năm 1988, người ta đã chứng minh rằng, một hệ thống ổn định không delay, chưa chắc ổn định với delay fixee, và một hệ thống ổn định với fixed delay, chưa chắc ổn định với delay thay đổi.

Mời các cao thủ đưa ra giải pháp.

Chúc vui.

[CuongQuay]

Điều khiển gì xa dữ dzậy với lại internet đang trong thời kỳ chiếm hữu nô lệ. Các cuộc chiến trên mạng nhằm sở hữu domain&hosting, đánh gục tên miền đang diễn ra tràn lan mà không có một chút can thiệp nào của chính phủ lâm thời. Thật là một hiểm họa lớn đối với xã hội loài người nếu như internet có thể tác động đến quá trình sản xuất của một hệ thống máy móc.
Hehe, TPC/IP đã lên tới v6 rồi mà vẫn không đáp ứng nhu cầu trong bài toán điều khiển thì tốt nhất là không dùng đến nó nữa

[qmk]

Tôi có nghe nói có cái gì đó là RTP thì phải không biết có dùng được không?

[falleaf]

Sự phức tạp nằm ở chỗ, nếu dùng RTP, thì bị mất mát dữ liệu. Nếu dùng TCP/IP còn chấp nhận dược vấn đề đêm dữ liệu, nếu dùng UDP thì mất là mất luôn. Điều khiển mà mất dữ liệu quá nhiều, kể như thua.

IPv6 chỉ mới được dùng ở Hàn và ỏ Nhật thì phải.

Cũng không ăn thua.

Truyền xa như vậy, là bởi vì ví dụ có một ứng dụng nào đó, cần thực hiện xa, lấy ngay đường truyền quốc gia ra sử dụng. Mà mạng internet, thì truyền cả thế giới, nên người ta thực hiện thí nghiệm ở khoảng cách xa, để vẽ được giản đồ pha của trễ. Kết quả F đã đưa mọi người tham khảo rồi đó 300ms là con số trung bình.

Đây là vấn đề rất hay mà chúng ta cũng nên nghiên cứu thử.

Chúc vui.

[CuongQuay]

Thông thường điều khiển qua internet người ta thường dùng web base interface để ra lệnh điều khiển, cũng có thể dùng mô hình client - server nhưng theo tôi thời gian trể đáp ứng 300ms là quá nhỏ đối với các hệ điều khiển có HMI ở xa. Còn bài toán của bác falleaf em đoán mò tí: chắc là bài tóan điều khiển hòa đồng bộ lưới điện quốc gia

[falleaf]

Thông thường điều khiển qua internet người ta thường dùng web base interface để ra lệnh điều khiển, cũng có thể dùng mô hình client - server nhưng theo tôi thời gian trể đáp ứng 300ms là quá nhỏ đối với các hệ điều khiển có HMI ở xa. Còn bài toán của bác falleaf em đoán mò tí: chắc là bài tóan điều khiển hòa đồng bộ lưới điện quốc gia

Chẳng phải lưới điện gì đâu, tui làm về robot mà, có liên quan gì đến điện tử với lại điện đâu?

F cũng chả có giao diện gì hết, chỉ nói đây là vấn đề nếu dữ liệu bị như vậy, thì người ta có những giải pháp nào để giải quyết? Cụ thể F nói luôn một số giải pháp như fix delay, dùng bộ đệm, dùng RTNP (thằng này đạt hiệu quả tốt hơn TCP/IP một tí trong điều khiển). 300ms là vô cùng lớn, nhớ là nó chỉ là giản đồ pha, và 300ms chỉ là điểm tập trung, còn phân tán, và tiến ra đến vô cùng là chuyện bình thường.

giờ bên này gửi cái sóng hình sin qua, bên kia nhận được ra sóng hình thang... thế là chết người rồi. Chưa kể, vd tay con người đưa qua máy, máy dập xuống, trễ vài trăm ms nó không nhận được tín hiệu có tay con người trong đó, ra lệnh dập, thế thì bỏ mẹ rồi còn gì ...

Kiểu vậy... đó là những vấn đề khó khăn cần phải giải quyết.

Ai có giải pháp?

[CuongQuay]

Ơ hơ, thế thì bác nên sửa cái chữ internet thành TCP/IP đi, hai cái này khác nhau nhiều lắm

[falleaf]

Bác hiểu sai rồi, kể cả RTNP thì cũng không đạt được kết quả tốt. Tôi chỉ nói TCP/IP để mọi người dễ hình dung thôi.

Delay là một hiện tượng không thể không có trong tất cả các loại chuẩn truyền, kể cả internet. Do vậy, giải pháp nào cho điều khiển qua internet?

UDP cũng có delay, nhưng giải pháp xử lý là đệm, và delay UDP vẫn có thể rơi ra vô cùng

Đó chính là vấn đề tôi quan tâm. Quan tâm về mặt lý thuyết, chứ còn làm mấy cái điều khiển như ở VN làm thí nghiệm thì không làm được.

Vì tôi làm điều khiển, không rành về mạng mấy, nên mới đặt ra câu hỏi này để thảo luận.

Chúc vui.

[anh_hao_hoa]

Có khoảng cách là có delay,mà mỗi tần số lại có khoảng delay khác nhau -> sinh ra méo dạng nơi đầu cuối,chưa kể các nguồn noise bên ngoài,thiệt là rắc rối.

Truyền dẫn số trên internet dùng TCP/IP,theo tôi người ta quan tâm đến khía cạnh chính xác của dữ liệu hơn là về mặt thời gian đến,vì delay nó phụ thuộc nhiều yếu tố khách quan mà mình đâu thể dự đoán trước được,như dung lượng mạng,tốc độ xử lý của các máy trạm trung gian,chất lượng đường truyền....

Chả vì thể mà người ta chỉ chia khung,đóng gói,điền địa chỉ mạng,chẳng thấy đề cập đến delay.

Nếu dùng net để điều khiển thời gian thực ra sao nhỉ,với khoảng cách 10000km,chẳng thấy khả thi tí nào,sao cái này giống dùng sóng siêu cao tần điều khiển robot nhặt đá trên mặt trăng ở khoảng cách xa thế nhỉ?,mà nghe nói con robot đó thấy cục đá trước mặt phải né trước vài giây đó.

[falleaf]

Đó là vấn đề cần quan tâm ở đây.

Phải coi delay là "the fact". Sự thật, delay là một hiện tượng luôn tồn tại, vậy thì chúng ta phải chấp nhận delay.

Như thế, làm sao để giải quyết hiện tượng này. Thực tế có hai cách.

Một cách là làm cho hệ thống ổn định với delay, có nghĩa là dùng các kiểu điều khiển ở tele side đại loại gọi là một trạm ở xa, để điều khiển hệ thống, mặt khác, dùng khả năng vision hoặc dự đoán để điều khiển ở trạm cố định.

Một cách khác, đó là hiểu về delay. Delay ảnh hưởng đến hệ thống như thế nào? Nói thì dễ, nhưng làm cách nào để hiểu được delay? Nhất là với tín hiệu feedback. Người ta có thể dùng passivity để damp mọi thứ, nhưng khi damp hết mọi tín hiệu, thì hệ sẽ ổn định, nhưng hệ ổn định rồi thì sao? Chúng ta lại không hiểu biết gì hết về hệ. Lúc đó, không còn phương hướng điều khiển.

Sự cân nhắc giữa transparency và stability nằm ở đây.

Chính vì thế, cần tìm những giải pháp nào để điều khiển qua mạng, và quan trọng nhất là xem delay như một sự thật.

Hãy tưởng tượng tới một thiết bị như thế này. Khẩu súng

Khi các bạn bóp cò từ từ, bạn bóp một lúc thì vẫn chẳng thấy nó thay đổi gì, nhưng khi nó vượt qua một cái ngưỡng nào đó, thì súng nổ và đạn bay mất tiêu rồi.. Lúc đó, cái mình cần điều khiển lại là viên đạn.. Thế mới đau chứ.

Vậy trong trường hợp đó, mình làm thế nào?

[anh_hao_hoa]

Thì cũng như khẩu súng đó.khi đạn nằm trong súng thì muốn làm gì thì làm nhưng khi bắn ra rồi thì nó có trúng đích hay không thì có trời mà biết,cũng như dữ liệu thôi,khi đã gửi lên net thì mình đã bàn giao công việc còn lại cho nhà cung cấp dịch vụ rồi,việc tới trễ hay không trễ mình đâu có thể kiểm soát được,"mưu sự tại nhân,thành sự tại thiên" thôi.

Người ta dùng internet để truyền dữ liệu,chẳng có ai mà dùng để điều khiển cánh tay máy cắt cách xa 10.000km,mà lại đặt tính chất delay lên hàng đầu,quá rõ ràng đây là một ý tưởng không thực tế.

Nếu muốn vừa transparency vừa stability để điều khiển thì có mà thuê một kênh truyền riêng,tốn kém,tốn kém lắm haha.

Nếu đã khẳng định delay là "the fact",muốn cải thiện nó thì có mà cải thiện cả một hệ thống viễn thông.

[falleaf]

Delay là một sự thật, nhưng làm thế nào để điều khiển được, đó là vấn đề quan trọng, và thực sự là người ta vẫn đang đi tìm cách giải quyết cho nó. Mạng internet sau này sẽ mở rộng lên đến hàng Gbps cho người dùng bình thường, chuyện đó không còn xa.

Ở các nước, tốc độ 100Mbps là rất bình thường rồi, vậy thì khi lên đến Gbps không còn xa nữa. Nhưng delay vẫn là một cái fact.

Vậy thì cái cần thiết là tìm cách giải quyết nó, chứ không phải bàn ra hoặc là tán dóc đâu.

Chúc vui.

[anh_hao_hoa]

Nói chuyện với ông đúng mệt óc thiệt đó.

Ông học ngành gì vậy? ông nghĩ mạng internet là cái sợi dây điện,để ông truyền dữ liệu từ đầu này sang đầu khác chắc.Nó phải đi qua biết bao nhiêu là giai đoạn với nhiều yếu tố ảnh hưởng chứ có phải truyền là tới ngay đâu.

Đúng là người ta luôn tìm cách cải thiện delay,vì vậy mới sinh ra các giải thuật tìm đường đi ngắn nhất,chi phí ít nhất trên mạng...,nhưng công việc đó là công việc của người cung cấp dịch vụ,còn u là user,u dùng net để điều khiển robot của u,u làm gì có cái khả năng cải thiện cái delay đó,có chăng u nói là làm sao để xây dựng thuật toán để thích nghi với delay ngẫu nhiên do mạng tạo ra thì còn nghe được.

Tôi nói trên cơ sở có hiểu biết cơ bản chứ không phải ngồi không tán dóc với ông cho vui đâu.

Còn nếu ý ông muốn nói cách giải quyết làm sao để cái máy cắt của ông không bị ảnh hưởng bởi delay thì cái này ngoài tầm hiểu biết của dân viễn thông rồi đó,nó thuộc lãnh vực cơ điện tử hay tự động gì đó rồi. Ai làm điều khiển qua internet vào đây giúp nè

[tammao]

Cho phép tôi bon chen một chút. Giờ vào đây mới đọc được topic này. Tôi không biết nhiều về viễn thông nhưng tôi nghĩ là hình thức Chuyển mạch gói đang sử dụng trong internet hiện nay không thích hợp với việc điều khiển thời gian thực. Ngoài trễ do truyền dẫn còn có cả trễ do xung đột, quá nhiều xung đột dẫn đến lỗi trên đường truyền. Việc mở rộng băng thông chỉ có ý nghĩa về mặt tốc độ chứ không cho xác suất lỗi thấp hơn. Vì vậy nếu yêu cầu điều khiển từ xa thì nên nghĩ đến Chuyển mạch kênh (sử dụng đường dây điện thoại, hoặc yêu cầu cao hơn thì sử dụng tuyến thông tin cáp quang) cho phép kênh truyền được duy trì liên tục khi 2 bên thông tin liên lạc. Hoặc sử dụng công nghệ không dây, ví dụ như thông tin vệ tinh trễ đường truyền 0,25s liệu có chấp nhận được không?
Đây chỉ là thiển ý của tôi, nếu không đúng mong mọi người chỉ giáo.

[tammao]

Cái mà anh Fallef gọi là fixed delay, có lẽ không thể nào tồn tại trên mạng internet. Fixed delay chỉ có thể có với một đường truyền không tắc nghẽn, không xung đột. Hoặc nó là một đường truyền riêng biệt, hoặc nếu nó được tổ chức thành mạng (dùng chung đường truyền) thì phải sử dụng các hình thức ghép kênh TDMA, FDMA, CDMA