頻寬不等於雲端, 有錯誤觀念的人還真不少

我是做平面設計的
關於雲端這個概念
也只是停留在大概的想法
我的認知裡面
雲端是可以處理~運算的一台主機
所以終端也就是使用者的電腦
根本不需要裝軟體
上網就能工作
所以好像不需要多大的頻寬
因為上傳的都是指令~下載的只是一個影像
但是~
我們的工作需要的文件檔可能超乎一般人想像
一張全開的海報可能要有好幾百mb
照片的量幾百張也是常有的事
如果照雲端的概念
我的照片是不是要先上傳到主機
然後在主機上合成~編輯
那照片的上傳雖然跟雲端運算無關
但是幾百mb上傳可不是開玩笑
如果有像ftp那像方便當然很ok
目前的雲端就我麼的工作別來說好像很方便
但是雲端目前能執行
ps~ai~或是coreldraw嗎
還是目前只有能執行辦公室軟體
有沒有其他網站可以參考
不要把你自己的錯誤觀念放在大家的錯誤觀念上
為什麼舉例youtube 上次辦個現場演唱會就LAG的到死 這算哪門子的雲端技術
總歸一句還不如叫中華電信把價錢壓低 這樣我們台灣雲端技術才有可能持續發展
否則只能搞搞那種網頁和程式而已
既然樓主你說雲端沒關係到頻寬 那server不就可以接上10M/2M頻寬的線路就OK了?
說那根本是瞎話
要上雲端OS你比登天還難 這還沒關係到頻寬?
嵐夜 wrote:
台灣頻寬太差網路太貴這是大家皆知的事實
P2P跟雲端的概念都是建立在有良好的網路建設上,沒有都是空談

所謂的網路建設不是只有很快的網路而已,
要有雲端運算, 那也要有運算中心, 可以做分散運算跟備援的動作.
我想這才是基本的東西吧.
當然有上下傳100Mb很好很強大,
只是運算在哪?
當然, 最基本的就是可以把整個企業的資訊系統, 流程跟應用程式都放在網路上.
不管是公共的還是私有的, 但如果是公共的,
會需要相當大的可分散的運算中心, 因為會需要服務的對象或是應用會相當多.

嵐夜 wrote:
所以日本香港擁有那麼大的頻寬都是用來抓盜版資源? 偷竊別人心血不想花成本的?
你把這些言論發表到香港日本論壇上,不被砲死才怪

那又怎樣? 香港跟日本人是貴族?
會抓的就是會抓, 不管你是哪一國人都一樣.

嵐夜 wrote:
BT也是要有基本對稱的上下傳輸吧
沒有對稱的話光BT上傳就把頻寬吃光了,要怎作其他的上網應用?
這時候只好限制BT上傳,或是抓完就關,所以問題點還是在台灣的網路


這是倒因為果, 拿頻寬來做理由跟本不合理.
要分享, 上傳少少留個10K也可以呀, 怎麼會不夠用?
跟本就是一堆人抓完就跑所以才會斷種.
因為把資源留給下一個種才能抓更多,
跟本就不完全是頻寬的關係, 使用者習慣佔的因素更大.

嵐夜 wrote:
你要把許多client的工作放到運算中心處理?? 許多=大量的上傳頻寬=台灣不可能
再把結果丟回來?? 大量的結果=大量的下載頻寬

這要看你要做的應用或運算是啥.
如果你可以傳個XML文字, 然後在client端組成也可以.

嵐夜 wrote:
先把居住環境跟基礎建設弄好,這我舉雙手贊成阿
但是先把日本&香港&韓國所擁有的高速網路環境建設好阿
還是說台灣只能跟爛的比較? 等爛到一個極致,也沒人在乎了


當然是先把居住環境跟基礎建設弄好.
你可以沒有ADSL網路, 但沒辦法不出門吧?
台灣還沒順利地發展雲端, 關鍵絕對不是頻寛, 而是使用習慣與軟體的配合 ...

前面提到一個Office文件20MB, 而20MB要經常地上下傳 ...
1. 20MB的文件根本不應該經常地上下傳, 這根本只是以使用本地系統的習慣去使用雲端系統, 你確定你需要雲端嗎?
2. 需要傳大量"非必要"資料的系統, 也根本不是成熟/最佳化過的系統, 軟體端有待努力

否則像 google的chrome OS, 不就是隨時都要幾百MB的資料上下傳?
但在chrome OS原本的設計中, client端是沒有可供儲存的硬體的 ...

參考看看
一堆人搞不清楚client-server跟雲端有什麼不同...

幾十年前x11就可以透過網路運作了...為什麼他是client-server不是雲端...

ftp也是雲端,ptt也是雲端...雲那麼多,難怪這幾天一直下雨。

小葉叔叔 wrote:
ps~ai~或是coreldraw嗎
還是目前只有能執行辦公室軟體
有沒有其他網站可以參考



可以

還很順

但前提是你要有學術網路般的頻寬

開ai只要5秒鐘,連我裝SSD都沒那麼快

雲端的速度快到嚇死人......不論是網路(學術)還是硬體

但是遇到小水管要傳到家裡.......


http://www.mobile01.com/topicdetail.php?f=507&t=1582370&p=1
chiang:香腸說不定我比你還多
小葉叔叔 wrote:
我是做平面設計的關於...(恕刪)


雲端應該是多台電腦分散處理資料

平面設計這個應該短期不會變成雲端技術

除了office外

我想大概企業方面如ERP系統會優先走雲端..........



總之就是那種資料量大而且需要及時運算的會比較有需求

搞不好以後F1也是收集大量現場即時資料瞬間丟到雲端處理然後再即時自動調整車輛特性
請勿購買韓國品牌,買伊索比亞的產品人家還會和您說謝謝,買韓國產品他們只會笑你笨再桶你一刀
嵐夜 wrote:
台灣頻寬太差網路太貴...BT也是要有基本對稱的上下傳輸吧
沒有對稱的話光BT上傳就把頻寬吃光了,要怎作其他的上網應用?
這時候只好限制BT上傳,或是抓完就關,所以問題點還是在台灣的網路(恕刪)


說的真好

要是網路有1G雙向對稱

上傳我開50mb可能沒有問題,甚至到100??

到時候慢的應該是硬碟的IO了

然後CPU資源又會被占去跑這塊

就要換SSD跟好U了

頻寬.....真的要大啊= =

Ailio wrote:
Office Online 要編輯一個20MB文件(這容量不算誇張吧)
以光纖2M上傳(200kB/s)來說 要傳約 100秒
下載則是需要約 20秒
因此不考慮 雲端伺服器要處理多久 光是傳輸檔案到雲端處理 再傳回來...
...不過目前主力在推的雲端 強調的是 主機這邊不負責運算 只負責傳輸資訊...(恕刪)


我目前是還沒用過office online但我猜頂多第一次上傳是傳完整的檔案 但接下來在瀏覽器中開起則應該是開啟檔案的片段 不會這麼笨每次開檔就要完整下載 改完再完整上載

另外主力再推的雲端是不負責運算只負責傳輸!?!?!?!?
諸如Amazon,Google等都是主要在推運算的 Amazon有提供隨選的運算服務 簡單說你可以"訂閱"你要運算的量 用量來計費

可以見得大家對雲端都太多猜測跟憑感覺去解釋...
Shawn732 wrote:
這是倒因為果, 拿頻寬來做理由跟本不合理.
要分享, 上傳少少留個10K也可以呀, 怎麼會不夠用?
跟本就是一堆人抓完就跑所以才會斷種.
因為把資源留給下一個種才能抓更多,
跟本就不完全是頻寬的關係, 使用者習慣佔的因素更大.(恕刪)


我覺得不能這樣講啊
現在很多P2P軟體常常開機就常駐在那
然後一直消耗你的上傳頻寬
達成你說的"分享"

問題是當我們的頻寬小到可憐
開個程式上傳就把可用的下載頻寬分掉一大部分了
那誰還會願意把程式常駐阿
雖然程式自己沒法自動管控頻寬也是一個可著手的部分
但 把用戶頻寬加大不才是治標的辦法嗎?

小弟覺得就像城市的發展一樣
一個地方要繁榮一定要有道路(省道、交流道)或是火車站
高鐵發展就比較慢一點吧!畢竟成立時間還很短
而高速公路也隨著時代拓寬了
你要說我們的頻寬不用拓寬嗎?

文章分享
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 33)

今日熱門文章 網友點擊推薦!